Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

typescript package tsconfig flags and console output #10939

Open
MastroLindus opened this issue Feb 24, 2020 · 6 comments
Open

typescript package tsconfig flags and console output #10939

MastroLindus opened this issue Feb 24, 2020 · 6 comments

Comments

@MastroLindus
Copy link

@MastroLindus MastroLindus commented Feb 24, 2020

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.

  1. The typescript package doesn't respect the tsconfig flags, and many of them are hardcoded inside the meteor/babel package.
    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

  1. No output of the compilation is shown in the console.
    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.

@afrokick
Copy link
Contributor

@afrokick afrokick commented Feb 24, 2020

There is a PR for decorators meteor/babel#28

@stale
Copy link

@stale stale bot commented Mar 27, 2020

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.

@stale stale bot added the stale-bot label Mar 27, 2020
@MastroLindus
Copy link
Author

@MastroLindus MastroLindus commented Mar 29, 2020

not stale

@stale stale bot removed the stale-bot label Mar 29, 2020
@stale
Copy link

@stale stale bot commented Apr 30, 2020

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.

@stale stale bot added the stale-bot label Apr 30, 2020
@MastroLindus
Copy link
Author

@MastroLindus MastroLindus commented Apr 30, 2020

not stale

@stale stale bot removed the stale-bot label Apr 30, 2020
@perbergland
Copy link

@perbergland perbergland commented May 11, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.