I'd suggest using the --outDir option, so TS writes the .js files to a different directory which you can easily blow away.
You should aim for deployment process where outDir would be in .gitignore and building of the JS files would happen on a build server.
This is the kind of stuff that makes the "incremental" adoption argument hard for me to swallow. If I can't rewrite a .js file to .ts without any further ripple effects within the project, then it's not truly incremental.
I wrestled with this stuff last week and ultimately ended up going with flow since it gave me type checking _and_ incremental adoption, without complicating my existing babel/webpack stack.
Your .js files should typically be relative to each other, so unless you're using absolute paths (which you usually shouldn't!), this hasn't been a problem for other users. Is there something that I'm missing?
I want the ability to convert any existing js file within the project to ts without having to touch a single other source file. I also want the type checker to assume that if I don't have a type definition for a package, that I don't want the use of that package to be type checked (without being forced to rewrite my ES6 imports to commonjs).
I was able to do this with flow but not typescript.
Is there something I'm missing?
Let me know how that ends up working out!
[1]: https://github.com/TypeStrong/ts-loader [2]: https://github.com/s-panferov/awesome-typescript-loader
A.ts importing B.ts would be `import * as A from "./B"`, where the transpiled A.js file would import from `./B.js` rather than the original A.ts file.
Furthermore you can mix JS into your compilation process and the TS compiler will* accommodate you by compiling your JS alongside your TS code.[1]
* TypeScript 1.8
>[ts] Experimental support for decorators is a feature that is subject to change in a future release. Set the 'experimentalDecorators' option to remove this warning.
When using the angular-cli,