NoA-Ignite-dk / eslint-config

ESLint config for JS projects
0 stars 0 forks source link

NX Config requires manuel removal of NX generated eslint settings. #24

Open mthines opened 2 years ago

mthines commented 2 years ago

When generating a new lib using NX it automatically generates a .eslintrc.json file which looks somewhat like this:

{
    "extends": ["plugin:@nrwl/nx/react", "../../.eslintrc.json"],
    "ignorePatterns": ["!**/*"],
    "overrides": [
        {
            "files": ["*.ts", "*.tsx", "*.js", "*.jsx"],
            "rules": {}
        },
        {
            "files": ["*.ts", "*.tsx"],
            "rules": {}
        },
        {
            "files": ["*.js", "*.jsx"],
            "rules": {}
        }
    ]
}

The current setup requires us to delete the "plugin:@nrwl/nx/react" part, in order to get it working. I think we should find a solution which doesn't conflict which the natural flow of using NX.

Error

[Error - 1:37:36 PM] Error: Plugin "import" was conflicted between "libs/theme/.eslintrc.json » ../../.eslintrc.json » @noaignite-dk/eslint-config/nx » ./typescript » ./index.js" and "libs/theme/.eslintrc.json » plugin:@nrwl/nx/react » plugin:@nrwl/nx/react-base".
    at mergePlugins (/Users/madsthinescoello/Workspaces/nx-boilerplate/node_modules/@eslint/eslintrc/lib/config-array/config-array.js:201:19)
    at createConfig (/Users/madsthinescoello/Workspaces/nx-boilerplate/node_modules/@eslint/eslintrc/lib/config-array/config-array.js:304:9)
    at ConfigArray.extractConfig (/Users/madsthinescoello/Workspaces/nx-boilerplate/node_modules/@eslint/eslintrc/lib/config-array/config-array.js:480:33)
    at CLIEngine.isPathIgnored (/Users/madsthinescoello/Workspaces/nx-boilerplate/node_modules/eslint/lib/cli-engine/cli-engine.js:991:18)
    at CLIEngine.executeOnText (/Users/madsthinescoello/Workspaces/nx-boilerplate/node_modules/eslint/lib/cli-engine/cli-engine.js:900:38)
    at ESLint.lintText (/Users/madsthinescoello/Workspaces/nx-boilerplate/node_modules/eslint/lib/eslint/eslint.js:607:23)
    at func (/Users/madsthinescoello/.vscode/extensions/dbaeumer.vscode-eslint-2.2.2/server/out/webpack:/eslint-server/src/eslintServer.ts:1616:67)
    at withESLintClass (/Users/madsthinescoello/.vscode/extensions/dbaeumer.vscode-eslint-2.2.2/server/out/webpack:/eslint-server/src/eslintServer.ts:1661:10)
    at validate (/Users/madsthinescoello/.vscode/extensions/dbaeumer.vscode-eslint-2.2.2/server/out/webpack:/eslint-server/src/eslintServer.ts:1614:8)
    at /Users/madsthinescoello/.vscode/extensions/dbaeumer.vscode-eslint-2.2.2/server/out/webpack:/eslint-server/src/eslintServer.ts:1550:10
jdpnielsen commented 2 years ago

I think the root cause of this issue is that we provide plugin dependencies via the shareable config, instead of forcing downstream consumers to install modules as peerdependencies. We instead use a patch mechanism provided by https://www.npmjs.com/package/@rushstack/eslint-patch, due to this longstanding, unresolved, issue in eslint: https://github.com/eslint/eslint/issues/3458

I don't see any way to make solution from the eslint-config side of things. One thing we cool look at is providing patched versions of the generators for nx, which work together with our ecosystem.

jdpnielsen commented 2 years ago

Good news on this front, the new eslint format (https://github.com/NoA-Ignite-dk/eslint-config/issues/42) should resolve this issue. Now we just need to wait for nx to change over, or replace the built in generators.