3 ms·

So how are you guys building TS for web apps? I've been using VS Code, putting classes into namespaces and it builds with commonJS, which I concatenate into a s

by neals 10y ago

So how are you guys building TS for web apps? I've been using VS Code, putting classes into namespaces and it builds with commonJS, which I concatenate into a single file that I load into a website. That last part is in need of change because you're not supposed to concatenate commonJS. So how have you been delivering your code to the browser?

salehenrahman 10y ago
I'm currently using a "TypeScript loader" for either Webpack or Browserify. If that seems too much, the other option is to output the compiled code as AMD modules [1]. But I have not tried it myself. Regardless, the option is still there, and, IMO, it seems like a painless transition away from concatenation. http://stackoverflow.com/a/36320145/538570 http://stackoverflow.com/a/36320145/538570
stupidcar 10y ago
We're experimenting with using TypeScript 2.0 for compilation, and webpack 2 for bundling. You can configure TypeScript 2.0 to compile most TS/ES6 syntax to ES5, but to leave the module statements (e.g. import and exports) as ES6. Webpack can then analyse your ES6 module tree and perform "tree shaking", a form of dead code elimination where unused modules are excluded from the compiled bundle. This will become increasingly useful as more libraries are authored in ES6 / TypeScript, as it will allow you to import the whole of a framework like Angular or React, but only ship the parts of it that you actually use in your application.
- stupidcar 10y ago
  And I wanted to add that, while webpack can appear a little intimidating at first, it's actually very easy to setup, and in many ways much simpler than the kind of jerry-rigged concatenation and minification workflows we used to build with Gulp and Grunt.
tomduncalf 10y ago
I've been using Typescript with Webpack (and Babel) for the last 9 months or so and in general been very happy with it, I'd highly recommend it as you get all the Webpack and Babel goodness (hot module reloading for React, async/await, the option to use Babel plugins etc.) on top of Typescript. I've written a step by step guide to setting up Typescript, Webpack and React at http://blog.tomduncalf.com/posts/setting-up-typescript-and-react/ http://blog.tomduncalf.com/posts/setting-up-typescript-and-r... if you're interested to try the set up out.
WorldMaker 10y ago
In the past I've used TS with AMD/RequireJS. These days I've been using TS with JSPM and SystemJS, with various combinations of Babel in the mix and JSPM/System bundler. I have projects that configure SystemJS to use TS itself as the only ES2015/TS transpiler (and thus no emit necessary in development, let the browser compile it, which makes for a fairly nice rebuild). You can even use TS directly as your bundler in this case if all you want to bundle are your TS sources as it supports the SystemJS registration format. I also have some projects that still use Babel as a transpiler and TS emitting ES2015+JSX to it (still in the JSPM/SystemJS stack). I've particularly needed this because TSX is great but it's support for non-React TSX emission is still somewhat lacking in my opinion versus what easily works in Babel.

by neals 10y ago

salehenrahman 10y ago

I'm currently using a "TypeScript loader" for either Webpack or Browserify. If that seems too much, the other option is to output the compiled code as AMD modules [1]. But I have not tried it myself. Regardless, the option is still there, and, IMO, it seems like a painless transition away from concatenation. http://stackoverflow.com/a/36320145/538570 http://stackoverflow.com/a/36320145/538570

stupidcar 10y ago

We're experimenting with using TypeScript 2.0 for compilation, and webpack 2 for bundling. You can configure TypeScript 2.0 to compile most TS/ES6 syntax to ES5, but to leave the module statements (e.g. import and exports) as ES6. Webpack can then analyse your ES6 module tree and perform "tree shaking", a form of dead code elimination where unused modules are excluded from the compiled bundle. This will become increasingly useful as more libraries are authored in ES6 / TypeScript, as it will allow you to import the whole of a framework like Angular or React, but only ship the parts of it that you actually use in your application.

stupidcar 10y ago
And I wanted to add that, while webpack can appear a little intimidating at first, it's actually very easy to setup, and in many ways much simpler than the kind of jerry-rigged concatenation and minification workflows we used to build with Gulp and Grunt.

tomduncalf 10y ago

I've been using Typescript with Webpack (and Babel) for the last 9 months or so and in general been very happy with it, I'd highly recommend it as you get all the Webpack and Babel goodness (hot module reloading for React, async/await, the option to use Babel plugins etc.) on top of Typescript. I've written a step by step guide to setting up Typescript, Webpack and React at http://blog.tomduncalf.com/posts/setting-up-typescript-and-react/ http://blog.tomduncalf.com/posts/setting-up-typescript-and-r... if you're interested to try the set up out.

WorldMaker 10y ago

In the past I've used TS with AMD/RequireJS. These days I've been using TS with JSPM and SystemJS, with various combinations of Babel in the mix and JSPM/System bundler. I have projects that configure SystemJS to use TS itself as the only ES2015/TS transpiler (and thus no emit necessary in development, let the browser compile it, which makes for a fairly nice rebuild). You can even use TS directly as your bundler in this case if all you want to bundle are your TS sources as it supports the SystemJS registration format. I also have some projects that still use Babel as a transpiler and TS emitting ES2015+JSX to it (still in the JSPM/SystemJS stack). I've particularly needed this because TSX is great but it's support for non-React TSX emission is still somewhat lacking in my opinion versus what easily works in Babel.