Is there a better way of using parserOptions.project?

[richardsengers]

As the specs state: Do not use parserOptions.project within your root .eslintrc.json, but I would like to use for all my projects and libs

https://github.com/cartant/eslint-plugin-rxjs

It just doesn't feel good to include this within every project and lib and it's easy to forget when someone generates a new lib or project.

So my root .eslintrc.json looks like this:

{
  "root": true,
  "ignorePatterns": [
    "**/*"
  ],
  "plugins": [
    "@nrwl/nx",
    "rxjs-angular"
  ],
  "overrides": [
    {
      "files": [
        "*.ts"
      ],
      "parserOptions": {
        "project": [
          "./tsconfig.*?.json"
        ]
      },
      "rules": {
        "rxjs-angular/prefer-takeuntil": [
          "error",
          {
            "alias": [
              "untilDestroyed"
            ],
            "checkComplete": true,
            "checkDecorators": [
              "Component"
            ],
            "checkDestroy": true
          }
        ]
      }
    },
    {
      "files": [
        "*.ts"
      ],
      "extends": [
        "plugin:@nrwl/nx/typescript"
      ],
      "rules": {}
    },
    {
      "files": [
        "*.ts"
      ],
      "extends": [
        "plugin:@nrwl/nx/angular",
        "plugin:@angular-eslint/template/process-inline-templates"
      ],
      "rules": {
        "curly": "error",
        "@nrwl/nx/enforce-module-boundaries": [
          "error",
          {
            "enforceBuildableLibDependency": true,
            "allow": [],
            "depConstraints": [
              {
                "sourceTag": "*",
                "onlyDependOnLibsWithTags": [
                  "*"
                ]
              }
            ]
          }
        ],
        "@typescript-eslint/no-non-null-assertion": [
          "off"
        ],
        "@typescript-eslint/no-unused-expressions": [
          "error",
          {
            "allowTernary": true
          }
        ],
        "@typescript-eslint/naming-convention": [
          "error",
          {
            "selector": "default",
            "format": [
              "camelCase"
            ],
            "leadingUnderscore": "allow"
          },
          {
            "selector": "variable",
            "format": [
              "camelCase"
            ],
            "leadingUnderscore": "allow"
          },
          {
            "selector": "variable",
            "format": [
              "PascalCase",
              "camelCase",
              "UPPER_CASE"
            ],
            "modifiers": [
              "exported"
            ]
          },
          {
            "selector": [
              "interface",
              "typeLike",
              "enumMember"
            ],
            "format": [
              "snake_case",
              "PascalCase",
              "camelCase"
            ]
          },
          {
            "selector": "property",
            "format": [
              "snake_case",
              "camelCase"
            ],
            "leadingUnderscore": "allow"
          }
        ],
        "@typescript-eslint/member-ordering": [
          "error",
          {
            "default": [
              "public-static-field",
              "public-instance-field",
              "protected-static-field",
              "protected-instance-field",
              "private-static-field",
              "private-instance-field",
              "constructor",
              "public-static-method",
              "public-instance-method",
              "protected-static-method",
              "protected-instance-method",
              "private-static-method",
              "private-instance-method"
            ]
          }
        ]
      }
    },
    {
      "files": [
        "*.html"
      ],
      "extends": [
        "plugin:@nrwl/nx/angular-template"
      ],
      "rules": {}
    },
    {
      "files": [
        "*.js"
      ],
      "extends": [
        "plugin:@nrwl/nx/javascript"
      ],
      "rules": {}
    }
  ]
}

Is this still a bad practise? Should I change this?

[the-ult]

Definitely interested in this.

We are using multiple ESLint plugins. One of them is eslint-rxjs
But our linting is extremely slow atm. (3min local with parallel=3 and up to 16 min in CI).
Only a few apps.. And not to many libraries.

What would be the proper way to setup ESLint?

{
  "files": ["*.ts", "*.tsx", "*.js", "*.jsx"],
      "rules": {
        "@nrwl/nx/enforce-module-boundaries": [ ...   ]
},
{
      "files": ["*.ts", "*.tsx"],
      "settings": {
        "import/extensions": [".ts"],
        "import/parsers": {
          "@typescript-eslint/parser": [".ts"]
        },
        "import/resolver": {
          "typescript": {
            "alwaysTryTypes": true,
            "project": "./tsconfig.*?.json"
          }
        }
      },
      "plugins": ["unused-imports"],
      "extends": [
        "plugin:@nrwl/nx/typescript",
        // "plugin:@typescript-eslint/recommended-requiring-type-checking"
        "plugin:unicorn/recommended",
        "plugin:sonarjs/recommended",
        "plugin:import/recommended",
        "plugin:import/typescript"
      ],
      "rules": {
        ...
        }
},
{
      "files": ["*.ts", "*.tsx"],
      "parser": "@typescript-eslint/parser",
      "parserOptions": {
        "ecmaVersion": 2019,
        "project": ["tsconfig.*?.json"],
        "sourceType": "module"
      },
      "plugins": ["rxjs-angular"],
      "extends": ["plugin:rxjs/recommended"],
      "rules": {
      ...
      }
 },
  // Is it OK to put this in the root eslintrc?
 {
      "files": ["*.ts"],
      "extends": ["plugin:@nrwl/nx/angular"],
      "rules": {
        "@angular-eslint/component-class-suffix": [
          "error",
          {
            "suffixes": ["Component", "Dialog", "Form", "Layout", "Container", "Page", "Root"]
          }
        ]
      }
    },

[galah92]

Also interested in this.

[darckoune]

Hello !
I'm also interested in this problem.
I am no eslint expert, so I'm just trying things out.

I tried several things:

// root eslintrc.json
{
  "parserOptions": {
    "project": "./tsconfig.*?.json"
  },
}

This one works, but has bad performances (7s / lib for me)

// project eslintrc.json
{
  "overrides": [
    {
      "files": ["*.ts", "*.tsx", "*.js", "*.jsx"],
      "parserOptions": {
        "project": "./libs/my-lib/tsconfig.*?.json"
     }
   }
 ]
}

This also works, but I have to update every eslintrc.json file...
It has better performances though (5s / lib)

I don't really understand the difference between the two, the first one seems to be using my tsconfig.base.json file maybe ?

[darckoune]

Ok, so to everyone wondering about this, here is what I found and understood. Sadly, this is not explained in the docs (or I was not able to find anything about it).

• The first solution I proposed above, using the root eslintrc.json is not the good solution. It scales very poorly as your repo grows. We reached 20s / library on our repo after creating 100+ libs.
• The second solution, that involves specifying the parser options in every library is the way to go. The processing time per lib remains the same as the repo grows.

The problem is that it is very annoying to set this option manually for every lib (and it is very easy to forget it). But I then realised that the library generators had an option called setParserOptionsProject. When enabled, the generator automatically generates the right eslintrc.json configuration ! But the problem remains, it is very easy to forget to enable this option in the generators.

The solution we came up in our team was to create our own generators (https://nx.dev/recipes/generators/local-generators) and stop using the default ones. I think this is the way to go to enforce some consistency in the workspace. You create your own generators with just a few parameters and you call nx generators with the parameters you see fit.

So we created our own library generator that always calls nx native generators passing the setParserOptionsProject: true parameter (and it does a bunch a other things to ensure that our workspace stays consistent).

Here is a part of this generator :

export default async function (
  tree: Tree,
  {
    name,
    framework,
    // [...]
  }
) {
  
  // [...]

  switch (framework) {
    case LibraryFramework.NONE:
      await genericLibraryGenerator(tree, { ...commonSettings, setParserOptionsProject: true });
      break;
    case LibraryFramework.ANGULAR:
      await angularLibraryGenerator(tree, {
        ...commonSettings,
        setParserOptionsProject: true,
        // [...]
      });
      break;
    case LibraryFramework.NEST:
      await nestLibraryGenerator(tree, {
        ...commonSettings,
        setParserOptionsProject: true
        // [...]
      });
      break;
  }

  // [...]

  await formatFiles(tree);
  return () => {
    installPackagesTask(tree);
  };
}

Hopefully, this will help someone ^^

[richardsengers]

Nice catch. Thanks for the update

[JakubPawlak]

Based on solution from @darckoune (thanks a lot!), I am sharing similar solution but without creating custom generators. The outcome is the same. Maybe someone will find it useful.

You can specify default parameters for generators in nx.json file. This way you can set defaults for all developers. Developers will simply call nx g @nx/angular:library my-ui-lib and the rest will be already set up under the hood in your own monorepo setup.

Open nx.json file in your monorepo and add generators section.

{
  (...)
  "generators": {
      "@nrwl/angular:library": {
        "setParserOptionsProject": true
      }
    },
  }
}

You will have to provide this setup for all your generators collections like @nx/nest:lib etc.

[Lonli-Lokli]

I am getting a popular ESLint was configured to run ... However, that TSConfig does not / none of those TSConfigs include this file
https://typescript-eslint.io/linting/troubleshooting#i-get-errors-telling-me-eslint-was-configured-to-run--however-that-tsconfig-does-not--none-of-those-tsconfigs-include-this-file

But I see that tsconfig.lib.json includes src/**/*.tsx

Does anyone know the reason?

[cwagner22]

did you find a solution? Looks like it's because files outside of src are being lint while tsconfig only targets files inside src

[cwagner22]

I finally found a solution to this madness. In root .eslintrc.json: (or per project)

    {
      "files": ['*.ts', '*.tsx', "*.js", "*.jsx"],
      "parserOptions": {
        "project": [
          "./tsconfig.*?.json"
        ]
      },
      "rules": {}
    },
    {
      "files": ['*.ts', '*.tsx', '*.js', '*.jsx', '*.json'],
      "excludedFiles": ['src/**/*.{ts,tsx,js,jsx}'],
      "parserOptions": {
        "project": null
      },
      "rules": {
        "@typescript-eslint/naming-convention": "off",
        "@typescript-eslint/dot-notation": "off",
        "@typescript-eslint/no-implied-eval": "off",
        "@typescript-eslint/return-await": "off"
      }
    },
    // { or if you just want to ignore a few files:
    //   "files": [
    //     "./vite.config.ts",
    //     "./package.json"
    //   ],
    //   "parserOptions": {
    //     "project": null
    //   },
    //   "rules": {}
    // },

Thanks to https://stackoverflow.com/a/72842477/1494428.
I guess an alternative would be to lint only the src folder.