-
Notifications
You must be signed in to change notification settings - Fork 26.2k
fix(compiler-cli): pass config path to ts.parseJsonConfigFileContent #29872
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
Conversation
You can preview 7ca6bc8 at https://pr29872-7ca6bc8.ngbuilds.io/. |
You can preview c65bd7b at https://pr29872-c65bd7b.ngbuilds.io/. |
The config path is an optional argument to `ts.parseJsonConfigFileContent`. When passed, it is added to the returned object as `options.configFilePath`, and `tsc` itself passes it in. The new TS 3.4 [incremental](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html) build functionality relies on this property being present: https://github.com/Microsoft/TypeScript/blob/025d82633915b67003ea38ba40b9239a19721c13/src/compiler/emitter.ts#L56-L57 When using The compiler-cli `readConfiguration` the config path option isn't passed, preventing consumers (like @ngtools/webpack) from obtaining a complete config object. This PR fixes this omission and should allow JIT users of @ngtools/webpack to set the `incremental` option in their tsconfig and have it be used by the TS program. I tested this in JIT and saw a small decrease in build times in a small project. In AOT the incremental option didn't seem to be used at all, due to how `ngc` uses the TS APIs. Related to https://github.com/angular/angular-cli/issues/13941.
You can preview d2f0592 at https://pr29872-d2f0592.ngbuilds.io/. |
…ngular#29872) The config path is an optional argument to `ts.parseJsonConfigFileContent`. When passed, it is added to the returned object as `options.configFilePath`, and `tsc` itself passes it in. The new TS 3.4 [incremental](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html) build functionality relies on this property being present: https://github.com/Microsoft/TypeScript/blob/025d82633915b67003ea38ba40b9239a19721c13/src/compiler/emitter.ts#L56-L57 When using The compiler-cli `readConfiguration` the config path option isn't passed, preventing consumers (like @ngtools/webpack) from obtaining a complete config object. This PR fixes this omission and should allow JIT users of @ngtools/webpack to set the `incremental` option in their tsconfig and have it be used by the TS program. I tested this in JIT and saw a small decrease in build times in a small project. In AOT the incremental option didn't seem to be used at all, due to how `ngc` uses the TS APIs. Related to https://github.com/angular/angular-cli/issues/13941. PR Close angular#29872
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
The config path is an optional argument to
ts.parseJsonConfigFileContent
. When passed, it is added to the returned object asoptions.configFilePath
, andtsc
itself passes it in.The new TS 3.4 incremental build functionality relies on this property being present: https://github.com/Microsoft/TypeScript/blob/025d82633915b67003ea38ba40b9239a19721c13/src/compiler/emitter.ts#L56-L57
When using The compiler-cli
readConfiguration
the config path option isn't passed, preventing consumers (like @ngtools/webpack) from obtaining a complete config object.Related to https://github.com/angular/angular-cli/issues/13941.
What is the new behavior?
This PR fixes this omission and should allow JIT users of @ngtools/webpack to set the
incremental
option in their tsconfig and have it be used by the TS program.I tested this in JIT and saw a small decrease in build times in a small project. In AOT the incremental option didn't seem to be used at all, due to how
ngc
uses the TS APIs.Does this PR introduce a breaking change?
Other information