I’ve been struggling a lot lately with TypeScript. I did get it to work with Meteor but it was a lot of work. I don’t think though that I will end up using it in production because it’s too hacky.
In your next version what do you think about supporting TypeScript out of the box? It would be a great addition to the Meteor offering. I think many serious people and projects are embracing TypeScript. It would be super nice to have Meteor suggest that people adopt typed JS because it’s the future and it’s the intelligent way to write code.
Type-checkers like TypeScript and Flow are too subjective IMO. Some people want to use them, some people want to just use pure JavaScript. I wouldn’t want it forced on me. An option, though, maybe.
I agree, TS should be a first class citizen in Meteor, its simply a much better dev experience even if you never really use the language as the type definitions are far superior. IMO its much more than Flow and isn’t just about types.
There’s no reason it will be forced, its like React vs Blaze or ES2015 support, choose what works for you.
Like so, Meteor would offer everything TS configured and ready to go ‘out-of-the-box’ and suggest forward-looking best practices of typing. All .ts (or .tsx) files would automatically be converted to .js (or .jsx) files. Warnings would be displayed in console and/or command.
That’s all. People are still absolutely free to use ‘normal’ JS.
One thing I found with TS was that ‘it just works’. Flow is somewhat less easier to get started with.
But, TS is still working on a few things that Flow has but TS does not have. See https://github.com/Microsoft/TypeScript/pull/7140. I think they have implemented it though now. IMO TS will be a standard very soon.
This was the biggest thing for me. Also it saved me all of the trouble of also setting up babel, editor support, etc - just one tool to do all the stuff I need instead of many.
Interesting. I set up a project with Flow, and honestly I didn’t find it too complicated. Just a few npm packages to install, some edits to .bablerc and .flowconfig. I’ll have to check out TypeScript as I haven’t given it a fair assessment yet.
I’m not sure I like that TypeScript is its own file extension and transpiles into JS, whereas Flow is just embedded in the JS files. Flow seems to function more like ESLint, analyzing and making suggestions, whereas TypeScript is a transpiler.
Yeah for me it really came down to two main things in favor of TypeScript:
Super duper easy to set up visual studio code with editor completion etc - I really couldn’t get Nuclide/Atom to work with Flow and I don’t have Webstorm
Availability of community type definitions - TypeScript has type definitions for basically every library ever, and my perception was that those are not as complete for Flow
Since typescript transpiles into regular js I don’t see why there would be a need for MDG to support it. There’s nothing to support if you setup your edit tool of choice properly. TS should be invisible to Meteor.
These are good points. And if someone is starting a new project, TypeScript is perhaps the best option.
If you already have a large app, Flow might be easier, because you can add a @flow annotation at the top of only the files you want to check with Flow. In theory, TypeScript is also possible per file, but it’s hard to work with it if you don’t go all in. I talked with @martijnwalraven about this, and he confirmed that this is the case with developing Apollo. All in is nice. If some files aren’t TypeScript it gets harder. Are there more people experiencing this?
I got Flow working with Meteor and wrote a blog post about it. I plan to add an example repo soon. Here is the post:
Were you able to comebine Flow and ESlint? It looks like you have to select either Flow or JS in webstorm, making it only check Flow types or ESlint rules, not both…
I don’t remember. I lost track of the state of my test repo. I really need to set aside some time and figure out Flow and Meteor testing, and integrate those into my boilerplate.
How does Unicode figure into Flow? function myFünc(sómeVar: string) { } ??
(Initially, I also had some trouble with different typings for client JS, server JS and shared JS)
If you mix and match TS with ‘regular’ JS files, you are in for some pain. It’s best either to go all in or not at all. The reference system of TS is both good and bad in the form it is right now.
I tried TS on an old ~3k standalone JS file. I incrementally moved to TS (so a part of it was JS, part TS). That worked out fairly well.
IMO in the long run as more and more people jump on the TS bandwagon and these things come up, the TS team is going to make it more easier to use TS. Right now everything is configurable and that’s a blessing and a curse. Opinionated TS would be nice for the general mass - something, which if Meteor offers, will set it quite apart.