You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fixes#2398
If the user has a particularly large node_modules folder and uses globs for `parserOption.project`, then the `glob` library can spend a decent chunk of time searching the `node_modules` folder.
In some cases, this can be on the order of hundreds to thousands of milliseconds.
This wouldn't be a problem, but for safety and correctness during a persistent parse, we have to do this check for every call to the parser (i.e. every file that's being linted).
Over a whole project, this can easily add up to many, many seconds wasted.
Previously, we:
- applied the project globs, one by one
- then manually excluded `tsconfig`s from the list.
This meant that we are always slow. I remember I did this because I had issues getting `glob`'s `ignore` option to work at all.
## The solution
`globby` is a better glob library:
- it accepts an array of globs, which saves us doing manual looping
- it supports exclusion globs (globs prefixed with `!`), which are evaluated as part of the glob process
- it has caching built in by default
This allows us to evaluate all of the `project` globs at once, as opposed to one at a time (so should be less duplicated work).
This also allows us to evaluate the `projectFolderIgnoreList` at the same time as the `project` globs (so should be no useless work done).
All of these together should cut the glob evaluation time down to ~50ms for the first parse, and ~2ms for each parse after that (due to caching).
For comparison, previously, in bad cases we would spend ~3-500ms, per project, per parsed file.
Example to illustrate how much faster this can potentially be:
For a project that provides 2 globs and has 100 files.
Before: 300ms * 2 * 100 = 60,000ms (60s)
After: 50ms + 2 * 100 = 250ms
This should also save a non-trival amount of time in other, more optimal setups.
BREAKING CHANGE:
- removes the ability to supply a `RegExp` to `projectFolderIgnoreList`, and changes the meaning of the string value from a regex to a glob.
Copy file name to clipboardExpand all lines: packages/parser/README.md
+4-3
Original file line number
Diff line number
Diff line change
@@ -57,7 +57,7 @@ interface ParserOptions {
57
57
lib?:string[];
58
58
59
59
project?:string|string[];
60
-
projectFolderIgnoreList?:(string|RegExp)[];
60
+
projectFolderIgnoreList?:string[];
61
61
tsconfigRootDir?:string;
62
62
extraFileExtensions?:string[];
63
63
warnOnUnsupportedTypeScriptVersion?:boolean;
@@ -156,12 +156,13 @@ This option allows you to provide the root directory for relative tsconfig paths
156
156
157
157
### `parserOptions.projectFolderIgnoreList`
158
158
159
-
Default `["/node_modules/"]`.
159
+
Default `["**/node_modules/**"]`.
160
160
161
161
This option allows you to ignore folders from being included in your provided list of `project`s.
162
-
Any resolved project path that matches one or more of the provided regular expressions will be removed from the list.
163
162
This is useful if you have configured glob patterns, but want to make sure you ignore certain folders.
164
163
164
+
It accepts an array of globs to exclude from the `project` globs.
165
+
165
166
For example, by default it will ensure that a glob like `./**/tsconfig.json` will not match any `tsconfig`s within your `node_modules` folder (some npm packages do not exclude their source files from their published packages).
0 commit comments