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.

[dagatsoin]

The only reason I still use barbatus:typescript is for the source map support. Do you guys know any workflow to support sourcemap in meteor with just tsc?

[scharf]

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?

I thought about this... Hmmm with the meteor section (in package.json) introduced in Meteor 1.7, it might be possible to do that quite easily.

[benjamn]

We're still going to want to wrap tsc with a Meteor compiler plugin, just because that's how Meteor works. Compiling TypeScript files outside of Meteor and letting Meteor think they're JS modules is never going to give an ideal experience.

[graywolf336]

@benjamn awesome! Any ideas when this will be started or any eta? I would love to get started using TypeScript within Rocket.Chat, since we will soon be having a definitions it only makes sense to move towards TypeScript..especially as a large open source project. ❤️

[scharf]

Compiling TypeScript files outside of Meteor and letting Meteor think they're JS modules is never going to give an ideal experience.

...but if it reduces the update time on each meteor watch cycle form 30 sec to 4 seconds it makes a difference -- and debugging the generated code without .map is better than wasting hours waiting for meteor to update....

[benjamn]

That 30 second baseline is based on barbatus:typescript 😉

[scharf]

That 30 second baseline is based on barbatus:typescript 😉

yes ... and I am sure a real integration of TypeScript into meteor could do much better 😉

I have days where meteor rebuilds 300 times and my hack saves me 2h of waiting time....

[dagatsoin]

One more spec to add to this story could be the source map for Android/iOS.
Actually with barbatus:typescript, on Android (don't know on iOS) the TS source map does not appears. There is only the final JS app shown on the chrome remote debugger, making debug more complicated.

[fabien-h]

Would it be possible to use TypeScript only for the tooling. With a noEmit in the config and to let babel handle all the compilation ?

(glad to see that TS support is coming tho)

[Bessonov]

I have been working with TypeScript for more than 2 years and love it. I see that many projects either switch to TypeScript or are developed with TypeScript right from the start. I am not a meteor user yet, but would like to try it. Therefore a big +1 for TypeScript only!

[al6x]

UP, any news? Is there official docs how to use TypeScript with Meteor?

[smeijer]

Did someone try this already with meteor?

https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-babel-7/

[PopGoesTheWza]

@yorrd as soon as the next repo for barbatus/ardonis:typescript is settled, I'll start contributing. Likely to first simplify dependencies (typescript-runtime should be merged into typescript-compiler imho) and better support TypeScript 3.2 feature and compiler.

@MastroLindus I was referring to DefinitelyTyped (where barbatus is listed among the maintainers) which could do with some/much improvements.

[MastroLindus]

@yorrd One thing I noticed recently is that I don't see anymore errors in the command line , I am using visual code as a IDE with the typescript version set to my workspace one, and if I open the file with it I do see the errors correctly, but not when meteor/adornis compile those files... I didn't notice this previously..

[yorrd]

@PopGoesTheWza finishing the move to a new repo and some minor cleanup today

@MastroLindus yeah. We had loads of warnings and I didn't have the nerve to only show fatal errors. You're right, that's high up on the todo list. Feel free to contribute once we got the repo. Sorry for not communicating this

[yorrd]

@MastroLindus fixed in the last version, syntax errors are shown now. For the rest, use your IDE :P (logging is kind of a mess right now, whatever, later)

@everyone new github repos @ https://github.com/Adornis/typescript and https://github.com/Adornis/typescript-compiler, please use the former for issues. Pull requests absolutely encouraged. Let's move the discussion there.

[alesn]

Hi @benjamn !
When using the official Typescript support in Meteor, which will hopefully be publicly available soon, can you provide information, if it is (would) be possible to run babel transform plugins on the generated JS code from TS files in the Meteor build system? It would be an important feature. (Or if not to use babel plugins generally, to use babel macros (with babel-plugin-macros), which might be easier because of the no configuration needed compared to using babel plugins)

[wesleyfsmith]

My workaround for using typescript in meteor has been to use the tsc --watch command, and then output all of my typescript target es6, which meteor then sees and does it's normal build process.

It's not perfect, but it's actually pretty fast and lets me use typescript without having to wade into meteor's build system.

You will need to declare some modules in order to import Meteor packages into typescript files for everything to play nicely together.

[yorrd]

we managed to make the typescript version variable in adornis:typescript. You can now "link" your project's typescript version into the package WITHOUT cloning it locally. Especially important because TypeScript 3.4 has a 20x performance regression in our projects...

[MastroLindus]

@yorrd In the adornis typescript readme it states that

TYPESCRIPT_EXTERNAL_PATH can be set to the path of a typescript node package anywhere on your computer to be able to use a different version that is used in the package by default -- only works when you clone locally, ask Meteor why, I don't know

Here though you mention that it works without cloning it locally.
Which one is it? :)
I am really interested as indeed 3.4 has a huge performance issue that should be fixed in typescript@next, and would like to adopt it without having to mess up with local cloning..

[yorrd]

@MastroLindus sorry, I thought we could do it. It seems Meteor doesn't forward env vars to the compiler by default. Maybe someone else knows more about this?

In our team, we currently just downgrade the adornis:typescript version to 0.9.8 which still uses 3.3.4000

[MastroLindus]

@yorrd that's too bad, thank you anyway for trying and sorry I cannot help too much, my knowledge of meteor internals is also very limited.

If you have access at least to the meteor root folder of the project, would it be possible, even without the need for an env var, to check if there's a typescript version installed in METEOR_ROOT/node_modules/typescript and use it if found?
as I would expect 99% of people that would like to use a specific version of typescript would just install it there with meteor npm install typescript. It wouldn't really be a flexible design as with an env-var, but it would still be better than getting stuck with a fixed unchangeable version..

[arichter83]

Of topic: In my pursue to move away from some meteor core stuff an be more compatible with standard components, I switched from adornis:typescript to ardatan:webpack with all it takes and I am pretty happy with compilation times, hot loading and such. Boopup time increased, but I am using typescript 3.4.1, so that might be related.

[yorrd]

@MastroLindus I agree. Played around with using the typescript version from the hosting project folder but didn't succeed so far. To be honest, I forgot what I have tried, it's been a few months. Honestly, at the moment I'm happy with just pushing the version manually, don't think it's worth the hassle. If someone wants to submit a pull request, I'll gladly accept.

@arichter83 we did try doing webpack in meteor, it just doesn't feel like meteor anymore tbh. The no config build system is one of the biggest reasons we use meteor.

[fgm]

@arichter83 we switched our main project from the standard build to webpack last year, and were happy with it in the beginning. Then we noticed recurring build time issues, extra machine load due to changes detection, then the package went unsupported, and fast-forward a few months, we're back on the standard Meteor build and getting all the improvements brought with the new versions. At this point, webpack no longer seems an worthy option for Meteor projects.

[MastroLindus]

@yorrd thank you so much for your efforts anyway. Hoping that sooner or later we will get a more official typescript compiler from MDG, going forward in this way for a few months is not that bad, and your plugin has come a long way too!

@arichter83 I join the others in saying that for me too weback is not the answer. We already don't use blaze anymore, we already use many NPM packages instead of atmosphere, we already opt-out reactivity when we don't need it, if we stop using the meteor build tools tools in favor of webpack at that point the whole point of using meteor in my opinion would become questionable.

[ceigey]

Hopefully some official input is still inbound.

In the meantime, we've been experimenting with using JSDoc typing. Perhaps not as clean, but seems to work well enough. There's some documentation scattered around the place on how to get started, e.g. on the TS Github wiki.

Biggest problem: there's nothing that warns you about type errors when running your application, so it can be tempting to ignore how correct your typings are.

When types hard to express in JSDoc format, you can drop down to .d.ts files like so:

// moduleUno/index.types.d.ts

export type MyFunc = <T>(param: T) => T

// moduleUno/index.js

// @ts-check
/** @typedef {import('./index.types.d.ts').MyFunc} MyFunc */
import { Meteor } from 'meteor/meteor'

/** @type {MyFunc} */
export let myFunc = param => {
  return param
}

/**
 * @template T
 * @param {T} param
 */
export let myOtherFunc = param => {
  return param
}

// moduleDos/index.js

import { myOtherFunc } from './moduleUno'
//       ^^^^^^^^^^^  -- should grab the type info from the other module
//                         (and it should be `<T>(param: T) => T`)

So if you need typechecking, don't want to commit to writing actual TypeScript in Meteor yet, and don't mind the Ecmascript package's performance, this seems like an OK alternative solution.

[nicu-chiciuc]

@ceigey We've been doing exactly that for almost half a year now and I would recommend it to anyone that is unable to commit completely to TS.

[StorytellerCZ]

Given that @benjamn talk at the next Meteor night is: Reimplementing Meteor in TypeScript, Module by Module
This looks quiet promising.
https://forums.meteor.com/t/bay-area-meteor-night-returns-july-9th/49297

[smeijer]

So how are you guys handling this now? babel-typescript? ardonis:typescript? Make tsc compile to a single file, and feed that to meteor?

It would be interesting to know how you've handled this. And if there is a migration path, that allows for a slow gradual migration instead of a huge refactoring job.

[ceigey]

So how are you guys handling this now?

@smeijer for my team, we're transitioning from using tsc manually and pointing Meteor to the build artefacts, to using ES6+ with JSDoc comments and .d.ts files (as hinted at in my above comment).

Both approaches require running tsc in --watch mode in the background, but the latter solution is far less intrusive (as there's no awkward situation where Meteor is requiring tsc to build the files first to run).

[yorrd]

@smeijer well I'm biased (disclaimer, adornis:typescript is my baby).

That being said, one of Meteor's strengths is its easy to use compiler which doesn't need hours of configuration work. So the only real solution is to have a compiler plugin. Working on incremental at the moment, could use help...

Every other solution involves having a separate process we have to manage or essentially not writing .ts which sucks as a solution imho.

[wesleyfsmith]

So how are you guys handling this now? babel-typescript? ardonis:typescript? Make tsc compile to a single file, and feed that to meteor?

@smeijer I'm still compiling my .ts and .tsx files into their .js and .jsx counterparts, which meteor then sees. It's not perfect but I think it's the best way to write typescript in an incremental fashion and doesn't involve getting into the meteor compilers core guts.

@yorrd I agree that one of the main reasons why I use meteor is that I don't want to get sucked into webpack configs and compiler settings, which is why it would be really nice to have first class support for typescript. Hopefully in a future release!

[benjamn]

Cross-posting this comment:

If you update to the latest beta by running

meteor update --release 1.8.2-beta.16

you can then run

meteor add typescript

to try the new typescript package introduced by meteor/meteor#10610. See that PR for a discussion of missing features and future plans.

Thanks to @scharf for starting this discussion, and to everyone else for investigating different strategies here. I know I didn’t comment much, but I was paying attention.

[alesn]

@benjamn Thank you. As I understand, the Meteor Typescript compiler has certain limitations. Can you clarify what advantages it brings compared to using the official Typescript compiler directly and having it generate js(x) files in a directory seen by Meteor build, so Meteor builds them into the final product (processing them through Babel)?

[doronrk]

@alesn I believe the PR convo here meteor/meteor#10610 will answer your questions.

[SimonSimCity]

@filipenevola This has been resolved, right? See previous comment.

[scharf]

@benjamn Thank you for your effort!

Since I opened it, I will also close it!