TypeScript Node 1.0

[blakeembrey]

From the issues I've seen logged thus far, I'm looking at rewriting ts-node into something that can suit more people. Here's some of the points that need covering for 1.0. Comments are appreciated.

• The goal is to be fast and production-ready out of the box (breaking change)
  • This means no type information, because that requires loading the entire project into memory
  • All files will transpile directly, in-memory using TypeScript transpileModule
  • Can enable a cache directory for a simple speed up
• One level up, semi-production ready, is the --typed flag
  • This transpiles the entire project and caches it once on startup
  • This has type information, but only for things in the initial project/require - subsequent requires of TypeScript files would fall back to the first point
• The next level, non production ready, is the --fully-typed flag
  • This is basically the current version of ts-node, suitable for a test suite
  • Everything needs to be in-memory because require can be "out-of-band". E.g. .ts -> .js -> .ts, not possible to handle by just the TypeScript compiler
  • We can think about way to fix this "out of band" require issue, but I believe changed files should always be re-loaded correctly (E.g. watching a test suite should get new diagnostics without re-compiling everything) /cc @basarat Any thoughts on this point? Maybe a way to serialize the compiler state in some form?
• The project flag is disabled by default (still considering this)
  • Enable ability to specify directory or file
• Compiler option flag - specify TypeScript compiler options via JSON
• All flags should have an environment variable for environments that can't specific CLI flags - E.g. Gulp, Grunt, etc.

[basarat]

The goal is to be fast and production-ready out of the box (breaking change)

💯 for this. People can have their (IDE | tsc -w) provide errors 🌹

[blakeembrey]

@basarat I wish I had my IDE (cough, cough, atom-typescript, cough) displaying errors, but they aren't part of my tsconfig.json file 😉 They don't need compiling, they don't need publishing and they break when moved away from the fixtures, etc.

But in general, yes. I've had a few people ask about production, when production is really just a 5 liner and simpler than the current ts-node implementation which supports everything else. Type checking is fantastic for the CLI and demos though, it's pretty nifty (will be better once node exposes multiline REPL support).

[tamascsaba]

👍

[blakeembrey]

This is released now. Some decisions above didn't stick in the end (E.g. kept the type checker as default, there's a lot of consumers using Gulp/Grunt/etc. that can't configure this easily). However, the main gist is there - there's file caching, --fast and other perf improvements.