meteor / meteor-feature-requests

A tracker for Meteor issues that are requests for new functionality, not bugs.
Other
89 stars 3 forks source link

Further embrace Typescript #415

Open rijk opened 3 years ago

rijk commented 3 years ago

Let me preface this with that I am a long time Meteor user (since 2014). Lately I have been using Next JS on a couple projects and so now I am coming back to Meteor with a fresh look, and there are some things that stand out a little. I think if we can shave off a couple of these rough edges, it will make the platform more friendly to newcomers, make it fit in more in the general JS ecosystem, and also make it more fun to work with even for veterans.

The main "huh" moments were around Typescript. I created this ticket to track the areas for improvement, feel free to add a comment if you have additional ideas. Happy to contribute if PRs are welcome as well, by the way.

  1. baseUrl/paths support More info in my forum post. In short: adding baseUrl to your tsconfig.json should 'magically' work with the Meteor build tool, like in NextJS.

  2. Meteor Methods 2.0 Methods are great but the API now feels a little outdated. For instance, you can only get Typescript definitions by bolting on something yourself, and proper validation only via a package. I feel Meteor needs a better story for this, it could be interesting to make a Meteor Methods 2.0 with validation, Typescript and maybe also promises built in.

  3. Same for publications? If we do the above, it might make sense to apply the update to publications as well.

  4. Fail build on Typescript errors A nice safety NextJS has, is to [fail production builds on Typescript errors]. It might sound scary, but it's actually really nice. You can easily circumvent it if it's invalid by either adding // @ts-ignore to specific lines, or disabling it altogether via project config.

perbergland commented 3 years ago

For item 1 and 4, please investigate using refapp:meteor-typescript (community package authored by me) instead of the built in package. It uses a proper "build all typescript files as a project" phase which includes reading the tsconfig.json file and emitting progress (with warnings and errors) to the meteor build console.

It doesn’t really do number 4 yet but could easily be changed to (optionally) fail a build if typescript diagnostics emits errors.

StorytellerCZ commented 3 years ago

For number 2 there are a few proposals, but right now there is no agreement on which one to adapt.