Meteor typescript support

[scharf]

AFAIK, the barbatus:typescript is the "official" typescript support.
However, it seems that the project is not updated anymore.

I think meteor should support typescript natively like meteor supports coffeescript.

Coffeescript is much less popular than typescript:

[scharf]

nathantreid:typescript-babel, a babel based typescript package support also has problems with changing versions of meteor/babel

[hexsprite]

Having 1st class TypeScript support for Meteor would be huge! There's also a problem with absolute imports that needs to be fixed as well with typescript. microsoft/TypeScript#13730

[benjamn]

I've been writing more and more TypeScript lately, and I approve of this direction. I'm going to need some help validating the functionality of this typescript package, once it's ready, but in general I plan to follow the structure of the packages/non-core/coffeescript package: separating the typescript and typescript-compiler packages, non-core, delegating to babel-compiler to avoid having to compile import and export, etc. The good news is that this doesn't have to be tied to any Meteor release, since doesn't need to be a "core" package.

[scharf]

I'm going to need some help validating the functionality of this typescript package

I am happy to help you out here!

but in general I plan to follow the structure of the packages/non-core/coffeescript package: separating the typescript and typescript-compiler packages, non-core, delegating to babel-compiler to avoid having to compile import and export, etc.

👍 since babel can handle typescript, that's the best way to go!

[smeijer]

I'm happy to test any beta release of the typescript > babel package 👍

[CoconutTheSlayer]

It would be great to have this.

[graywolf336]

@benjamn it would be great to see that support added, as we at Rocket.Chat are looking to move towards TypeScript (some of the packages we write extenerally and import are TypeScript) for our code internally. However, as mentioned the barbatus:typescript package isn't up to date with TypeScript and some reason the sourcemaps aren't working as expected (debugging in VSCode leads to the generated JavaScript files instead of the TypeScript).

[scharf]

...it gets more and more annoying to be struck with meteor 2.5 because many newer versions of type definitions use new features and do not compile with 2.5....

[benjamn]

@scharf We hear you!

[dagatsoin]

@scharf FYI babartus updated TS to 2.8

[scharf]

I made some experiments using barbatus:typescript versus tsc --watch.

It turns out, that on my project barbatus:typescript takes about 10 times longer to compile.

Scenario

• run meteor with VELOCITY_DEBUG=1 METEOR_PROFILE=1 meteor
• change a singe file

barbatus:typescript: 16 sec

 Top leaves:
| other plugin barbatus:typescript........................14,191 ms (3)
| linker File#getPrelinkedOutput.............................436 ms (296)
| getPrelinkedFiles toStringWithSourceMap....................256 ms (2)
| Target#minifyJs............................................170 ms (2)
| other compileUnibuild (the app)............................140 ms (3)
| other bundler writeFile....................................112 ms (239)
|
| (#5) Total: 16,592 ms (Rebuild App)

tsc --watch: 1.5 sec

tsc --watch reacts quite quickly and compiles the file.

| Top leaves:
| other Builder#copyNodeModulesDirectory.....................131 ms (25)
| other plugin ecmascript....................................121 ms (3)
|
| (#5) Total: 1,496 ms (Rebuild App)

Question

I wonder how long it would take when babel does the typescript compilation: Is it more like barbatus:typescript or more like tsc --watch?

[scharf]

Forgot to mention how long it really takes until the app updates: with barbatus:typescript it takes about 25-30 sec and with tsc --watch it takes about 4-5 sec. This adds up during a workday and gets really frustrating.

I have a 2017 MacBookPro (2,9 GHz Intel Core i7), some of my co-workers have slower computers and it takes up to a minute to update with barbatus:typescript.

[smeijer]

Wouldn't it be possible to let tsc compile to a dist folder, and have this dist folder watched by meteor? Or would that give to much overhead?

It doesn't sound efficient, as your then building two times. Kind of a 2 stage build. But if I understand @scharf correctly, he's already doing something like that and it seems to be a lot faster.