Wanting to contribute for Metadata Reflection and Decorators Support in TypeScript package

[ardatan]

When using typescript package in an Angular project, it doesn't have metadata reflection which Angular needs to have "experimentalDecorators": true and "emitDecoratorMetadata": true in compilerOptions of TS Compiler configuration which is missing in meteor-babel's preCompileTypescript. So this little change in meteor-babel wouldn't affect existing Meteor users but it would make Meteor support all those libraries using decorators and metadata reflection like Angular, TypeORM, TypeGraphQL, Inversify etc. I can create a PR for this issue if you want.
https://github.com/meteor/babel/blob/51258a2feb412131ec045a7fba613690d9854ad0/index.js#L149

But I think respecting tsconfig.json in the project would be better because there are some other compilerOptions, users may want to use now and later. If you want to force users in some options, you can throw an error during compilation process to make users change by themselves instead of overriding it which would be more consistent with the behavior of the IDE that respects tsconfig.json.

There is another option which is using babel-typescript(or respecting babelrc and add ts and tsx extensions to ecmascript package

meteor/packages/ecmascript/plugin.js

Line 2 in 3f88ccb

extensions: ['js', 'jsx', 'mjs'],

) and disabling default flow plugins to prevent conflicts inside meteor-babel so there would be single compilation process handled in babel completely. And in this case not to break the existing behavior for flow users, we can remove flow plugin for ts files only in meteor-babel package.

What do you think? @benjamn

[benjamn]

Here are my thoughts on the challenges of paying attention to tsconfig.json: #10610 (comment)

[ardatan]

@benjamn The actual issue is lack of these two additional options prevents users of Angular, Inversify and other kind of libraries to benefit from this typescript package. However adding those two options wouldn't affect the existing users. I also mentioned to use babel-typescript with the existing babel structure of meteor-babel that can be extended by other babel plugins. So my point wasn't only about respecting tsconfig.json.
I created that PR that makes people able to use this package with Angular and similar libraries/frameworks.
meteor/babel#28

[MastroLindus]

@benjamn I have the feeling that only a very limited amount of tsconfig settings will impact meteor's build (stuff like module, targets, etc), and that not allowing users to specify the other flags will create a lot more problems than the confusion of having that small set forced by meteor.

Couldn't we simply for the moment use a "best effort" approach to respect the tsconfig flags, and discard those that influence meteor's behaviour?
I am not a fan of this approach either, but between this and not been able to specify any flag at all I consider the latter much worse.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[afrokick]

not stale

[afrokick]

Also we use resolveJsonModule with decorators.

[afrokick]

@benjamn @filipenevola any news? It is a blocker for us to migrate from Adornis package to "native" typescript.

There is open PR to meteor-babel meteor/babel#28

[MastroLindus]

I am also blocked in migrating from Adornis to the typescript package until some flags in tsconfig.json are allowed: #10610 (comment)

In short I need at least

strict: true,
experimentalDecorators: true

to be allowed.

I really really really hope they get supported.
Honestly I would still prefer to allow people to specify what they want in their own tsconfig, and have Meteor make a best-effort approach of supporting them, but overriding the ones that can be problematic (output directories, modules, etc)

Edit:
ah, I was forgetting, another really important thing: output of compilation errors/warnings, relying on the IDE for that just doesn't work for us, too many cases of people not noticing an error because the ide didn't check it as it was not in an open editor, and so on. The main point of typescript of increasing security through compilation checks is just wasted if the compiler won't show errors in the output

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Urigo]

no stale.

I believe @ardatan gave a couple of possible solutions, can someone decide and offer one of them?
#10784 (comment)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Urigo]

no stale.

[ruohki]

is there a workaround until we can use that by default?

[ardatan]

You can use barbatus:typescript package instead of official one.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ardatan]

no stale.

[filipenevola]

Hi @ardatan I've talked with @perbergland about his typescript package as well (https://github.com/ref-app/meteor-typescript) and we should join efforts here to update the official typescript package in the best way for the community.

@zodern is also going to take a look in this package from Per to check if the performance could be improved.

We need to select a package to be the candidate for the new official package and then make PRs to update the actual official package.

Any thoughts on this?

@hexsprite and @leonardoventurini feel free to share your opinions as well.

[ardatan]

@filipenevola I think it is fine. The most important point is to have enough flexibility to support user's tsconfig.json (at least decorators).

[ruohki]

Does someone have a workaround to hack this into a installed meteor ~ those other typescript packages are just so slow or bug prone

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[afrokick]

1.12 should contains emitDecorator