4 ms·

I'd suggest using the --outDir option, so TS writes the .js files to a different directory which you can easily blow away.

Tx3 10y ago
Rob is exactly right that you should use --outDir You should aim for deployment process where outDir would be in .gitignore and building of the JS files would happen on a build server.
- rymohr 10y ago
  If you use --outDir, wouldn't the .js files that import the transpiled .ts files need to point to outDir instead? 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.
  - DanRosenwasser 10y ago
    Hey, I work on the TypeScript team. I hope you'll reconsider, and maybe you can fill me in on the issues you ran into. 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?
    - rymohr 10y ago
      Hey Dan, thanks for responding. I think the key point you may be missing (or perhaps I missed a flag somewhere) is that I want relative requires but I don't want the intermediate js and sourcemap files cluttering up my project (and assuming I have an existing babel/webpack stack I'm happy with -- I just want the type checking). 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?
      - DanRosenwasser 10y ago
        Hey rhymohr, I think I see what you mean. If you're already using something like Babel & Webpack, it should just be a matter of using a TypeScript loader like ts-loader[1] or awesome-typescript-loader[2]. TypeScript should just fit into that build step. Let me know how that ends up working out! [1]: https://github.com/TypeStrong/ts-loader https://github.com/TypeStrong/ts-loader [2]: https://github.com/s-panferov/awesome-typescript-loader https://github.com/s-panferov/awesome-typescript-loader
  - ihsw 10y ago
    The .js files don't import the transpiled .ts files -- the .ts files are written to import other .ts files using relative paths. 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 [1] https://github.com/Microsoft/TypeScript/issues/4792 https://github.com/Microsoft/TypeScript/issues/4792
ZoeZoeBee 10y ago
Hey Rob any idea why VSCode gives this warning on export class for Components? >[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,
- robwormald 10y ago
  Your tsconfig file should have that option set (as well as emitDecoratorMetadata).

Tx3 10y ago

Rob is exactly right that you should use --outDir You should aim for deployment process where outDir would be in .gitignore and building of the JS files would happen on a build server.

rymohr 10y ago
If you use --outDir, wouldn't the .js files that import the transpiled .ts files need to point to outDir instead? 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.
- DanRosenwasser 10y ago
  Hey, I work on the TypeScript team. I hope you'll reconsider, and maybe you can fill me in on the issues you ran into. 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?
  - rymohr 10y ago
    Hey Dan, thanks for responding. I think the key point you may be missing (or perhaps I missed a flag somewhere) is that I want relative requires but I don't want the intermediate js and sourcemap files cluttering up my project (and assuming I have an existing babel/webpack stack I'm happy with -- I just want the type checking). 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?
    - DanRosenwasser 10y ago
      Hey rhymohr, I think I see what you mean. If you're already using something like Babel & Webpack, it should just be a matter of using a TypeScript loader like ts-loader[1] or awesome-typescript-loader[2]. TypeScript should just fit into that build step. Let me know how that ends up working out! [1]: https://github.com/TypeStrong/ts-loader https://github.com/TypeStrong/ts-loader [2]: https://github.com/s-panferov/awesome-typescript-loader https://github.com/s-panferov/awesome-typescript-loader
- ihsw 10y ago
  The .js files don't import the transpiled .ts files -- the .ts files are written to import other .ts files using relative paths. 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 [1] https://github.com/Microsoft/TypeScript/issues/4792 https://github.com/Microsoft/TypeScript/issues/4792

ZoeZoeBee 10y ago

Hey Rob any idea why VSCode gives this warning on export class for Components? >[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,

robwormald 10y ago
Your tsconfig file should have that option set (as well as emitDecoratorMetadata).