5 ms·

It's worth noting that with upcoming Babel 7 it is possible to strip Typescript types like with Flow and use it just as a typechecker/linter [1]. This means fol

It's worth noting that with upcoming Babel 7 it is possible to strip Typescript types like with Flow and use it just as a typechecker/linter [1]. This means following things: - You don't need ts-loader/at-loader with Webpack anymore. You'll lose typechecking during webpack build but you can run it as separate step. Your editor will show them as usual still. - You can use all the Babel plugins with Typescript without running two compilers (should speed things up) - Should add first class support for React Native as it uses Babel (or at least no more 2-step builds) [1]: http://babeljs.io/blog/2017/09/12/planning-for-7.0#typescript http://babeljs.io/blog/2017/09/12/planning-for-7.0#typescrip... EDIT: For the curious here's my build configuration with Webpack demoing this with extra plugins https://gist.github.com/epeli/bb8ae386f9dbb2a4ae2159e1f265fd56 https://gist.github.com/epeli/bb8ae386f9dbb2a4ae2159e1f265fd...

msoad 9y ago
Some features like enums are not supported and why on the earth you want to lose the type checking?
- esamatti 9y ago
  Faster and simpler builds setups. And you don't really lose it as your editor will report the type errors. Flow is used like this all the time. Tried this on a project of mine. Enums seem to work fine for me. EDIT: There are some issues with enums indeed https://github.com/babel/babel/tree/master/packages/babel-plugin-transform-typescript https://github.com/babel/babel/tree/master/packages/babel-pl...
  - mattmanser 9y ago
    This seems like a recipe for disaster after a bad merge. If you have a team of more than one, this sounds like a silly thing to do.
    - lewisl9029 9y ago
      It's fairly common practice with Flow to run type-checks as a part of the build or test step in a standard build/test/deploy workflow in CI, which largely removes the possibility of bad merges arising from type errors. With TypeScript, using the TypeScript compiler, type-checking would simply happen in lockstep with your build step, whereas with the new Babel preset and a separate type-check process, you still have the option of running them in lockstep as 2 separate commands, but you also have the option of running them as separate jobs in parallel, likely leading to significantly shorter build times. It's definitely going to be a huge net improvement to my own workflow, but you're certainly free to stay with the status quo if you feel it suits you better.
  - stupidcar 9y ago
    Wouldn't the simpler build setup be to use TypeScript only for compilation? Why would you want to use Babel as well?
    - mariusmg 9y ago
      >Why would you want to use Babel as well? Because he thinks you can't do JS development without Babel.
    - 1_player 9y ago
      From what I understand, TypeScript doesn't do any transpiling, so if you want to use ES6/2017 features, you're going to need Babel. (I haven't used TypeScript yet, so I might be wrong)
      - gangstead 9y ago
        It does transpiling. You can set the compiler target to es3/es5/es6 in your tsconfig.json and then you don't need Babel.
      - pafje 9y ago
        Typescript has always transpiled to ES5 (by default it transpiles to ES3 actually). See: https://stackoverflow.com/questions/41173215/does-typescript-transpilation-handle-transpiling-es6-to-es5 https://stackoverflow.com/questions/41173215/does-typescript... The only counter-example that I know of is that async/await were initially only supported when transpiling to ES6, but this is not true since at least 2.2 (https://github.com/Microsoft/TypeScript/issues/5210 https://github.com/Microsoft/TypeScript/issues/5210).
    - bastawhiz 9y ago
      Babel makes it possible to do compilation that TS doesn't do. E.g., you can use esnext language features that TS doesn't support, like do expressions. You can also use babel plugins that add utility, like the Babel power-assert plugin.
  - pygy_ 9y ago
    One of the common pattern I use when developing with TS is: Change a type definition, look for red squiggles in the current file and fix them then save and build. The error log shows me the rest of the files that need fixing. How would you get that with Babel?
    - esamatti 9y ago
      I think this is just an editor concern. It could show a list of files with type errors. But you could just run "tsc --noEmit --watch" which will just report the project wide type errors to the console as you edit files.
    - deleted 9y ago
      [deleted]
  - hzoo 9y ago
    Yeah, it doesn't doesn't anything that is multi-file like const enums since Babel operates per file. (I work on Babel)
- lhnz 9y ago
  Perhaps you could run the type-checker separately on a 'prepush' hook.
- callumlocke 9y ago
  You don't lose it. You use type checking like a linter, to highlight issues as you type. If you also want to use it as an enforcer, you set it up as a pre-commit hook or a CI step or whatever you want. The idea is not to be forced to typecheck on every little incremental build during development. Sometimes I _know_ what needs to be done to get typechecking to pass (I can see the type errors highlighted in my editor after all) but I don't want to have to fix it before running my code to see how it behaves, because maybe I'm just playing around with an idea. There are pros and cons to typechecking and not typechecking, which is why both kinds of language exist. Annotation- stripping lets you get the best of both worlds.
hzoo 9y ago
I'll update the post to give an idea of how it works, thanks!
WorldMaker 9y ago
If you were going to do that, wouldn't it better to just use // @ts-check in JS files, a jsconfig.json for the Typescript compiler, and jsdoc pragmas?
- bastawhiz 9y ago
  For the same reason that Flow's dedicated type annotation syntax is the standard. It's just easier to use. This change will effectively make using ts as easy as using Flow, which is a huge win.
  - WorldMaker 9y ago
    Interesting. From my perspective using Typescript and its transpilation power entirely instead of Babel is even easier still. There's a lot less complexity in my builds if I don't need to manage Babel. From that perspective, Typescript has always been easier than Flow, too, though some of that is also bias from how hard Flow has been to get working on Windows up until somewhat recently. I realize though that there are many perspectives on this issue and I asked the previous question because I was indeed curious about your perspective, thanks.

msoad 9y ago

Some features like enums are not supported and why on the earth you want to lose the type checking?

esamatti 9y ago
Faster and simpler builds setups. And you don't really lose it as your editor will report the type errors. Flow is used like this all the time. Tried this on a project of mine. Enums seem to work fine for me. EDIT: There are some issues with enums indeed https://github.com/babel/babel/tree/master/packages/babel-plugin-transform-typescript https://github.com/babel/babel/tree/master/packages/babel-pl...
- mattmanser 9y ago
  This seems like a recipe for disaster after a bad merge. If you have a team of more than one, this sounds like a silly thing to do.
  - lewisl9029 9y ago
    It's fairly common practice with Flow to run type-checks as a part of the build or test step in a standard build/test/deploy workflow in CI, which largely removes the possibility of bad merges arising from type errors. With TypeScript, using the TypeScript compiler, type-checking would simply happen in lockstep with your build step, whereas with the new Babel preset and a separate type-check process, you still have the option of running them in lockstep as 2 separate commands, but you also have the option of running them as separate jobs in parallel, likely leading to significantly shorter build times. It's definitely going to be a huge net improvement to my own workflow, but you're certainly free to stay with the status quo if you feel it suits you better.
- stupidcar 9y ago
  Wouldn't the simpler build setup be to use TypeScript only for compilation? Why would you want to use Babel as well?
  - mariusmg 9y ago
    >Why would you want to use Babel as well? Because he thinks you can't do JS development without Babel.
  - 1_player 9y ago
    From what I understand, TypeScript doesn't do any transpiling, so if you want to use ES6/2017 features, you're going to need Babel. (I haven't used TypeScript yet, so I might be wrong)
    - gangstead 9y ago
      It does transpiling. You can set the compiler target to es3/es5/es6 in your tsconfig.json and then you don't need Babel.
    - pafje 9y ago
      Typescript has always transpiled to ES5 (by default it transpiles to ES3 actually). See: https://stackoverflow.com/questions/41173215/does-typescript-transpilation-handle-transpiling-es6-to-es5 https://stackoverflow.com/questions/41173215/does-typescript... The only counter-example that I know of is that async/await were initially only supported when transpiling to ES6, but this is not true since at least 2.2 (https://github.com/Microsoft/TypeScript/issues/5210 https://github.com/Microsoft/TypeScript/issues/5210).
  - bastawhiz 9y ago
    Babel makes it possible to do compilation that TS doesn't do. E.g., you can use esnext language features that TS doesn't support, like do expressions. You can also use babel plugins that add utility, like the Babel power-assert plugin.
- pygy_ 9y ago
  One of the common pattern I use when developing with TS is: Change a type definition, look for red squiggles in the current file and fix them then save and build. The error log shows me the rest of the files that need fixing. How would you get that with Babel?
  - esamatti 9y ago
    I think this is just an editor concern. It could show a list of files with type errors. But you could just run "tsc --noEmit --watch" which will just report the project wide type errors to the console as you edit files.
  - deleted 9y ago
    [deleted]
- hzoo 9y ago
  Yeah, it doesn't doesn't anything that is multi-file like const enums since Babel operates per file. (I work on Babel)
lhnz 9y ago
Perhaps you could run the type-checker separately on a 'prepush' hook.
callumlocke 9y ago
You don't lose it. You use type checking like a linter, to highlight issues as you type. If you also want to use it as an enforcer, you set it up as a pre-commit hook or a CI step or whatever you want. The idea is not to be forced to typecheck on every little incremental build during development. Sometimes I _know_ what needs to be done to get typechecking to pass (I can see the type errors highlighted in my editor after all) but I don't want to have to fix it before running my code to see how it behaves, because maybe I'm just playing around with an idea. There are pros and cons to typechecking and not typechecking, which is why both kinds of language exist. Annotation- stripping lets you get the best of both worlds.

hzoo 9y ago

I'll update the post to give an idea of how it works, thanks!

WorldMaker 9y ago

If you were going to do that, wouldn't it better to just use // @ts-check in JS files, a jsconfig.json for the Typescript compiler, and jsdoc pragmas?

bastawhiz 9y ago
For the same reason that Flow's dedicated type annotation syntax is the standard. It's just easier to use. This change will effectively make using ts as easy as using Flow, which is a huge win.
- WorldMaker 9y ago
  Interesting. From my perspective using Typescript and its transpilation power entirely instead of Babel is even easier still. There's a lot less complexity in my builds if I don't need to manage Babel. From that perspective, Typescript has always been easier than Flow, too, though some of that is also bias from how hard Flow has been to get working on Windows up until somewhat recently. I realize though that there are many perspectives on this issue and I asked the previous question because I was indeed curious about your perspective, thanks.