feat: new builder impl, new config schematic #120
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR completely refactors the implementation of builder to address the performance and memory issues that have been raised in multiple issues.
I generated a number of additional projects for the integration-test workspace and was able to reproduce the issues pretty consistently so this was good confirmation that the initial "get it working" implementation of the builder needed improving.
In fact the "get it working" origins of this meant that initially the builder was just a port of the TSLint builder from angular-devkit. That builder (and the one this PR is replacing) creates one (or usually multiple) full TypeScript Program(s) each time it runs in order to figure out what files should be involved in the linting run. Not only is this expensive, it is also work that is doomed to be repeated, because ultimately ESLint is going to be invoking
typescript-eslint
which will need to build a TypeScript Program to represent the files of the run as well. There is no way to share program data between these runs.Therefore the fundamental change of approach here is to use the builder as a very lightweight wrapper around ESLint, and then let
typescript-eslint
do the heavy lifting it needs to anyway.To maximise performance and memory consumption, and ensure that all editor tooling etc, works as expected a new
tsconfig.eslint.json
file per project will be used to precisely control what goes into the linting-related compilation.To mitigate any user pain around creating this extra config file, I have also included a new schematic in this PR which handles creating this automatically.
I have increased the detail and focus of the docs, and cover the updated process of migration from TSLint to ESLint.
After implementing these changes the multi-project integration-tests now run much faster and I have not seen any issues with OOM errors.
Because this is a major change it will be released as
v0.2.0-beta.1