eslint executor performance improvement

• I’d be willing to implement this feature (contributing guide)

Description

The ability to specify which tsconfig files to use when using eslint.

Motivation

Currently, linting a small (few lines), 0 dependency project within a large monorepo can be very slow.

Looking at the behavior, it seems that eslint is going through a lot of files unrelated to the project itself, likely from using the root tsconfig.

Being able to use the project’s tsconfig files (e.g. tsconfig.lib.json and tsconfig.spec.json) greatly reduces the linting time:

# 27 seconds with Nx
nx lint projectname --no-cache 
# 1 second with eslint
eslint --parser-options project:./packages/projectname/tsconfig.*.json ./packages/projectname/src/**/*.ts

Suggested Implementation

Add a new property to the @nrwl/linter:eslint executor schema, either:

• tsConfig (to match @nrwl/node:package) or
• project (to match eslint’s argument)

{
  "executor": "@nrwl/linter:eslint",
  "options": {
    "lintFilePatterns": ["packages/projectname/src/**/*.ts"],
    "tsConfig": "./packages/projectname/tsconfig.*.json"
  }
}

The string value would be passed as --parser-options project:<string-value-here>.

eslint --parser-options project:./packages/projectname/tsconfig.*.json ./packages/projectname/src/**/*.ts

A migration would update any existing targets that use the executor to include the new parameter for all projects.

Alternate Implementations

A more global parserOptions property that acts as a dictionary could also work, being more flexible but likely less user-friendly:

{
  "executor": "@nrwl/linter:eslint",
  "options": {
    "lintFilePatterns": ["packages/projectname/src/**/*.ts"],
    "parserOptions": {
      "project": "./packages/projectname/tsconfig.*.json"
    }
  }
}

Command-line:

eslint --parser-options project:./packages/projectname/tsconfig.*.json ./packages/projectname/src/**/*.ts

[meeroslav]

Ok, I see what you mean. I just tried on a repo with ~60 projects and nx lint run went to 4s, while eslint remained around 1s. I will look into this deeper. Thank you for your clarification!

[meeroslav]

In practice, our background daemon should remove most of the Nx overhead so as you said two runs should be very comparable.

Thank you for the clarification and sorry it took us so long to get to the bottom of this. I will close this issue. If we stumble upon this again we can open a new one.