Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Option to exclude project specs in parserOptions (e.g. node_modules) #1771

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

Closed
tkalliom opened this issue Mar 19, 2020 · 3 comments · Fixed by #1802
Closed

Option to exclude project specs in parserOptions (e.g. node_modules) #1771

tkalliom opened this issue Mar 19, 2020 · 3 comments · Fixed by #1802
Labels
enhancement New feature or request has pr there is a PR raised to close this package: typescript-estree Issues related to @typescript-eslint/typescript-estree

Comments

@tkalliom
Copy link

Repro
For a monorepo of apps looking something like category-a/operation-1/, category-a/operation-2, category-b/operation-1 etc., independent of each other, we still want to enforce a common set of style rules. We had this in our .eslintrc.js at the root:

{

  "parserOptions": {
    "project": "./**/tsconfig.json"
  }
}

Expected Result
The linting runs successfully.

Actual Result
After adding enough sub-applications, linting starts to fail with Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory. I suspect this is due to the glob catching also TypeScript libraries under various node_modules directories.

Additional Info
It would be nice if there was a way to leave out node_modules from the pre-parse after specifying a generic glob. One way to do this might be an option like parserOptions.projectExcludes. Another would be to respect .eslintignore also for the project specification – but maybe it’s better to keep .eslintignore for a single purpose?

Wwe worked around this by specifying "project": ["category-a/*/tsconfig.json", "category-b/*/tsconfig.json"].

Versions

package version
@typescript-eslint/parser 2.23.0
TypeScript 2.9.2
ESLint 6.8.0
node 10.15.2
npm 6.14.1
@tkalliom tkalliom added package: parser Issues related to @typescript-eslint/parser triage Waiting for team members to take a look labels Mar 19, 2020
@bradzacher
Copy link
Member

I believe most npm packages do not include tsconfigs in their output.
But even if they do, they don't include the ts[x]? files, so the tsconfig will match no files.

It'd be interesting to see how many npm packages you have installed actually have them. You can do this via the following snippet:

const {sync} = require('glob');
console.log(sync("./**/tsconfig.json"));

What does your project structure look like?
Do you follow the "standard" monorepo structure (i.e. the same structure we have in this repo)?
Or do you have another structure?


See issue on OOMs: #1192

OOMs happen because typescript isn't overly optimised for our usecase, nor is our codebase overly optimised yet.
As more projects get added, each one adds memory usage. We haven't figured out a strategy for purging projects from memory yet, so memory usage currently just grows.

As mentioned, NPM packages should have a tsconfig that matches zero files, so their impact on memory should be negligible. Your projects would be 99%+++ of the memory usage.

@bradzacher bradzacher added awaiting response Issues waiting for a reply from the OP or another party and removed triage Waiting for team members to take a look labels Mar 19, 2020
@tkalliom
Copy link
Author

See https://github.com/tkalliom/monorepo-typescript-linting-example/ for an example of a project where the wider glob catches enough node modules for the memory to run out

@bradzacher
Copy link
Member

Your example doesn't cause memory to run out for me, but it does show that I'm wrong, and there are many package maintainers that are lazy, and do not exclude the source files from their packages.

> const {sync} = require('glob');
undefined
> console.log(sync("./**/tsconfig.json"));
[
  './ecommerce/operation-a/tsconfig.json',
  './ecommerce/operation-b/tsconfig.json',
  './ecommerce/operation-c/tsconfig.json',
  './ecommerce/operation-d/tsconfig.json',
  './fulfillment/operation-a/tsconfig.json',
  './layers/ecommerce-shared/tsconfig.json',
  './node_modules/@bcoe/v8-coverage/dist/lib/tsconfig.json',
  './node_modules/@bcoe/v8-coverage/tsconfig.json',
  './node_modules/commandpost/tsconfig.json',
  './node_modules/dtsgenerator/example/add-prefix/tsconfig.json',
  './node_modules/dtsgenerator/example/tsconfig.json',
  './node_modules/dtsgenerator/tsconfig.json',
  './node_modules/rxjs/src/tsconfig.json',
  './node_modules/schemats/node_modules/typescript-formatter/example/tsconfig.json',
  './node_modules/schemats/node_modules/typescript-formatter/tsconfig.json',
  './node_modules/schemats/tsconfig.json',
  './node_modules/uri-js/tsconfig.json',
  './purchase/operation-a/tsconfig.json'
]

A few of those contain non-trivial ts sourcecode in their package, like dtsgenerator and rxjs.

In that case, I think that it makes sense to add a new option to ignore certain folders from the glob, defaulting to ['/node_modules/'].

@bradzacher bradzacher added enhancement New feature or request package: typescript-estree Issues related to @typescript-eslint/typescript-estree and removed awaiting response Issues waiting for a reply from the OP or another party package: parser Issues related to @typescript-eslint/parser labels Mar 23, 2020
@bradzacher bradzacher added the has pr there is a PR raised to close this label Mar 26, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 26, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request has pr there is a PR raised to close this package: typescript-estree Issues related to @typescript-eslint/typescript-estree
Projects
None yet
2 participants