Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign uptypescript package tsconfig flags and console output #10939
Comments
|
There is a PR for decorators meteor/babel#28 |
|
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 |
|
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 |
|
Is there any interest from the maintainers to move the TS plugin in this direction? There is some recent discussion around using babelrc for setting tsconfig options. but to make the TS compilation part of the build process so we can get proper support for build servers and console diagnostics has not been mentioned and it's unclear to me if there are underlying technical reasons preventing this or if there is something else |
Some of the issues below are already mentioned in other tickets, but I have the feeling that a proper generic issue is due to give it visibility, as for now the current package is unusable for many users.
I understand that meteor needs to control some compilation options in order to ensure that the whole build chain works as expected. Stuff like outDirs, module format, etc.
However:
There are many flags that are optional and meteor shouldn't have any saying about them. Stuff like "strict", "noUnusedLocals", etc.
Many of these flags directly impacts what kind of libraries we can use.
We are not allowed to specify "experimentalDecorators" and that can break many libraries that rely on them.
And the fact that "esModuleInterop" is forced to be false in order to optimize the flow with Babel, breaks many libraries that use commonjs or other module systems and that rely on the "import * as " syntax ( moment.js, agenda.js, sharp and many others)
In general it is very confusing for the end user that he can specify stuff in his tsconfig.json (and he still might need to do it for IDE integration) but the building process behaves differently
Using in-editor windows is not a solution to this. Most editors only show errors in opened files, and anyway the result could be different as there's no guarantee that the editor TS version is the same as the one used by meteor.
And in other contexts (like when building and deploying in another environment) it doesn't help anyway.
What I would expect:
I would expect that meteor would enforce only a very limited amount of flags, only the ones strictly necessary to its own functionality, and they should be documented somewhere.
For the rest it should try at least a best effort approach in order to respect user-configured flags in tsconfig.json.
And I would expect to at least have an option to enable typescript's warnings/errors to be visible in the output.