-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
tsc: TS5053: Option 'noEmit' cannot be specified with option 'composite' #36917
Comments
|
Thanks for the quick answer! When using |
Those declaration files are the metadata that |
I understand that
I'm really not against that change, but as #36588 blocks us from removing |
I've the same problem in a mono repo. so that I can continue to work, I created a tsconfig.test.json
to use it with --noEmit:
So I can lint my packages at least |
I have the same problem but with |
Don't use |
@weswigham Sorry, to clarify: we have So I'm wondering if there's a way to avoid having two config files. |
We have a similar issue. We have a monorepo and use path references, which requires |
agree, |
It did not "work perfectly" - it didn't do what it claimed to do (intelligently reuse build outputs as inputs where possible); the usage of |
@hollg you could pass |
The problem is that they can not be unset in command line. During development, it's good to have them, but for checking during commit, it'd be better to do something like |
|
I think allowing composite to be set to false (not true) seems like a better solution here. Looking into this. |
This works, thanks! |
@weswigham right now its impossible to use composite projects, where one of the project is react-based. Because Its a big issue because guess over 95% of react users use create-react-app. |
Should |
Closing this since we are now allowing passing |
For someone who found this thread after upgrading to TypeScript 3.8 and after passing |
Eject from create-react-app. |
TypeScript incremental build seems to be a problem for projects using Babel, like Next.js apps: "error TS5053: Option 'noEmit' cannot be specified with option 'composite'." So... microsoft/TypeScript#36917
* Update dependency typescript to v3.9.5 * Update dependency typescript to v3.9.5 * Fix name clashes in resolvers-types.ts with a hack I modified indent_style back to "space" in .editorconfig to avoid too much changes in this commit's diff. We still have the following problem: "error TS5053: Option 'noEmit' cannot be specified with option 'composite'." * Add --composite false to "typecheck:api" npm command TypeScript incremental build seems to be a problem for projects using Babel, like Next.js apps: "error TS5053: Option 'noEmit' cannot be specified with option 'composite'." So... microsoft/TypeScript#36917 * Suppress TS errors from mocked server context * Fix *Payload interfaces with a temporary hack * Fix directories in VS Code workspace config * Add --composite false to "typecheck:web" npm command * Add tsconfig.build.json to avoid incremental build For package/web, which uses Babel. * Replace GlobalFetch with WindowOrWorkerGlobalScope GlobalFetch was removed in TS 3.6.2: apollographql/apollo-link#1131 * Fix root "build" command to use tsconfig.build.json Co-authored-by: Renovate Bot <bot@renovateapp.com> Co-authored-by: Josias Iquabius <iquabius@gmail.com>
TypeScript Version: 3.9.0-dev.20200220 (broken in 3.8.2)
Search Terms: TS5053: Option 'noEmit' cannot be specified with option 'composite'
Code
Expected behavior:
Run a type-check with no errors, as in 3.7 and previous versions.
Actual behavior:
Additional comments:
We use
composite
in ourtsconfig.json
to ensure the output directory structure is always the same.We also use
--noEmit
in our CI pipelines to ensure type-checking before building a Docker image.Is the
--noEmit
the best way to do type-checking without the overhead of running an entire build (with output files) or this breaking change should really be reverted?Related Issues:
#36588 - attempt to remove the
composite
fromtsconfig.json
and use as CLI flag when building projectThe text was updated successfully, but these errors were encountered: