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

@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

@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.

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.

not stale

Also we use resolveJsonModule with decorators.

@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

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

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.

no stale.

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

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.

no stale.

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

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

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.

no stale.

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.

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