How to make ESLint run in package dir in monorepo?

In a monorepo setup (for example one that uses lerna or yarn workspaces) commands are run with the CWD of the command being that of the package they are running in. For examle,

 

```bash

yarn workspace my-lib run eslint # equivalent to `cd my-lib; yarn run eslint`

# or

yarn run lerna run eslint # equivalent to `cd my-lib; yarn run eslint`, for each workspace

```

 

When running ESLint, the dir it's being run from can impact how the configuration is interpreted (for example, rules related to TS which might require specifying the location of `tsconfig.json` or rules related to imports, such as `import/no-extraneous-dependencies` which requries specifying the location of `package.json`)

How can I tell WebStorm to run ESLint from within the packages, like lerna or yarn does, instead of the project root dir? 

The VS Code extension for ESLint has a setting for specifying the CWD of ESLint called `eslint.workingDirectories` (it even has an auto feature). Is there a similar setting for WebStorm?

17 comments
Comment actions Permalink

No way, there are no settings for this.

the IDE starts a ESLint process for every package.json that contains a eslint dependency and process everything below it as if it was invoked with .bin/eslint **/*.js.

Some examples:
1.

- .eslintrc with rules
- package.json with eslint dependency
- some
  - nested
    - project
      - package.json *without eslint*

We lint the nested project with rules from the top-level config because this is what running eslint **/*.js in the root directory does, this is what VS code does regardless of working directories configured for ESLint.
If the user does not want to lint the nested project, some/nested/project should be added to eslintignore.

  1.  
- .eslintrc with rule X
- package.json with eslint dependency
- some
  - nested
    - project
      - .eslintrc with rule Y and root:false
      - package.json with eslint

The nested project is linted with rules X and Y because this is what running from the console produces with any working directory. The working directory is never taken into account when evaluating configs. Configs are also merged if the nested config is empty or absent.
To specify that the nested project should only be linted with it's own rules, "root": true should be used.

0
Comment actions Permalink

Just to be clear, what I'm asking about is how to change the cwd of the eslint executable that WebStorm uses (which apparently isn't possible, but is possible in VS Code) to match the behavior (and therefore the results) of popular tools such as yarn or lerna frequently used in monorepos.

Also, to further emphasize, I'm not sure if this statement, "The working directory is never taken into account when evaluating configs." is a reflection of what WebStorm does or how you think ESLint works, but let me clarify that when it comes to ESLint, the CWD *does* matter and does impact how files are linted. The examples I mentioned in the first post (settings related to `@typescript-eslint/parser` or `eslint-plugin-import`) rely on the cwd ESLint is run from.

Therefore, it is highly desirable to be able to set this directory to match common monorepo workflows. Relying on ESLint being declared as a dependency is not a robust approach as monorepos may use monorepo-wide dependencies (ie, declared in the root `package.json`, but not in individual packages) which lerna and yarn will find even when ESLint is invoked from within a monorepo package.

This missing feature in WebStorm, which is supported by VS Code for a reason, would be highly valuable to devs working on large-scale projects that leverage all of ESLint's functionality and embrace common monorepo workflows. Would you consider adding this option to WebStorm? Can't really be that hard now can it? After all, the ESLint extension for VS Code is open source and free, yet WS is a product we pay for 🤔

 

2
Comment actions Permalink

please feel free to file a request for this feature to youtrack, https://youtrack.jetbrains.com/issues/WEB

0
Comment actions Permalink

Ebardaji Did you file the request ? I would to vote up for it.

The difference between VS Code and WebStorm, that in fact WebStorm indeed does not support mono repos, even for the "root: true" case. So, right now I have to switch to VS Code.

0
Comment actions Permalink

Hi Aleksey Chemakin, I did not. I'm using VS Code.

0
Comment actions Permalink

Elena Pogorelova I'm trying to use ESLint exactly as you describe, but it is not working.

- project root
- .eslintrc.js
- package.json (does not include eslint)
- packages
- foo
- package.json (eslint is in dependencies)
- code.js

If I run eslint from the project root:

~/project root $ yarn eslint packages/foo/code.js

I get a no-extraneous-dependencies error.

On the other hand, if I run eslint from the package:

~/project root/packages/foo $ yarn eslint code.js

I get no errors.

As this is a monorepo, I'm always going to be running eslint the latter way: from the individual package. However, WebStorm is still showing me an error in my code.js file, the error I saw in my console when I ran from the project root. So clearly it isn't respecting the workspace scope. It's running eslint from the project root.

0
Comment actions Permalink

please follow https://youtrack.jetbrains.com/issue/WEB-44936 and linked tickets for updates

0
Comment actions Permalink

With the new version of webstorm 2020.2 and the correction of the bug mentioned by Elena Pogorelova I have a configuration for a mono repo that was working before but no longer works and I cannot understand why.

My eslint dependencies are defined in my root package.json.

I have a global `.eslintrc.json` configuration file at the root of my monorepo and some overrides into my packages with

{
"extends": "../../.eslintrc.json",
"rules": {
"import/no-extraneous-dependencies": [
"error",
{
"packageDir": [
".",
"packages/mobile"
]
}
]
},
}

With this configuration eslint on command line works, webstorm 2020.1 works but with webstorm 2020.2 I have some errors about some extraneous dependencies.

0
Comment actions Permalink

Since 2020.2, as a result of fixing the above mentioned issue, the IDE looks for the directory closest to the linted file which contains the .eslintrc.* file (or package.json file with either "eslintIgnore" or "eslintConfig" property) when selecting a working directory for the ESLint process...

0
Comment actions Permalink

I now understand my problem : I previously tweaked my configuration to work with WebStorm 2020.1 and other IDEs used in my team.

I was explicitly executing eslint from the root of the repo both for my command line and for the ide.

The problem here is that other IDEs execute eslint from the root of the repo so now I can't have a unique configuration that works with all IDEs.

0
Comment actions Permalink

Would it be possible to have a configuration option so we can choose between executing eslint from the closest directory with some eslint config or from the root directory of the project ?

0
Comment actions Permalink

Please feel free to file a request for adding this option to youtrack, https://youtrack.jetbrains.com/issues/WEB

0
Comment actions Permalink

Hope to have better support for lerna and the surrounding ecology, just like the reason for using ts, the front-end projects are becoming larger and larger, and we are also looking for some kind of local module management tool like Java Maven. And lerna is currently the best. Especially when vscode has implemented this function, webstorm should support it out of the box by default. After all, webstorm still has some advantages over vscode (this is why we still buy jetbrains), but this The gap is narrowing, and there are other advantages of vscode (wsl, markdown, multi-language, larger ecological support)

0
Comment actions Permalink

Sebastian,

I don't know if I understand correctly but the execution
nx lint name-library
starts the linking of this project / library
then does not take the configuration of this project inheriting from the main?

0
Comment actions Permalink

Hi Piotr,

The difference between the old way of dealing (before 2020.2) and the new one (2020.2 and after) is the directory from where the lint command is executed in a monorepo.

In my case, to have things work before 2020.2 my `lint` command in the packages of my monorepo was doing a `cd ../..` to execute the lint command from the root. With the new version, I had to change this to have my lint command to be executed from my package directory.

Regards

Sébastien

1
Comment actions Permalink

In the upcoming Webstorm 2020.3, you will be able to configure the working folder explicitly, see https://youtrack.jetbrains.com/issue/WEB-47135#focus=Comments-27-4419848.0-0

0
Comment actions Permalink

Thanks,all

I didn't know that :) 

Thank you for your help 

Piotr

0

Please sign in to leave a comment.