Vscode-eslint: Improve extension in a Multi repository setup with Lerna.

Created on 29 Aug 2019 · 12Comments · Source: microsoft/vscode-eslint

I've tried everything to make this work with mono repositories but nothing helps. My eslint config works when run from command line but it fails to work in vsc.

Here is my directories structure:

web - root directory
web/package.json - all the eslint packages are added here
web/.eslintrc - main eslint config
web/packages/a/.eslintrc - eslint config that extends .eslintrc from the root
web/packages/a/tsconfig.json - TS config

When I run eslinter from command line everything works perfectly but in the vsc I constantly see error that tsconfig.json file can't be found in the web directory. It's pretty annoying as it should look for the file in each sub package. It works in eslint cli, so don't know why it doesn't work in vsc.

I've also tried changing settings:

{
  "eslint.enable": true,
  "eslint.packageManager": "yarn",
  "eslint.workingDirectories": [
    {
      "directory": "./packages/a",
      "changeProcessCWD": true
    },
    {
      "directory": "./packages/b",
      "changeProcessCWD": true
    }
  ]
}

and then it works but it's far from perfect as I would like to use something like glob pattern and I can't in the directory property. I guess that it would also take the first tsconfig.json file that it finds in this directories which doesn't necessary mean the one that is dedicated for a given sub package

feature-request help wanted

Source

lukejagodzinski

👍8

Most helpful comment

There is a new version (Insider testing) that addresses this is two ways:

glob pattern support
more eager working directory changes.

The version can be found here: https://github.com/microsoft/vscode-eslint/issues/815

dbaeumer on 4 Dec 2019

❤4

All 12 comments

@lukejagodzinski I am pretty sure that eslint in the terminal will fail as well if you execute the command from the workspace root (e.g. the web folder).

ESLint itself is very sensitive to the current working directory in terms of resolving files. Since it why if in the terminal you have to do a cd to make eslint work correctly you need to tell the extension these working directories using eslint.workingDirectories.

This being said if you can successfully validate in the terminal from the root then please provide me with a GitHub repository I can clone that demos the behavior and I will investigate why it fails in the extension.

dbaeumer on 30 Aug 2019

@dbaeumer it work in the root directory because I'm using lerna + yarn workspaces which makes it possible. As I said I can't set eslint.workingDirectories as I would need to use glob pattern and it doesn't work there and I don't want to list every possible sub package there as I'm not sure how it really works in such context. I will prepare reproduction

lukejagodzinski on 30 Aug 2019

@dbaeumer ok I've create reproduction repository here https://github.com/lukejagodzinski/vsc-eslint-monorepo-bug.git

There is also README file explaining everything and what scripts to run to lint from root and package directory. Let me know what you think about it

Btw. Thank you for quick response! :)

lukejagodzinski on 30 Aug 2019

👍1

For me that fails the same way whether you validate in the terminal or in VS Code

capture

Validating in the right directory works in the terminal

capture

and does work in VS Code when setting the working directory.

capture

I see the argument that you use lerna to work around the eslint working directory affinity but the extension does have the same limits as eslint itself has.

I am open for a pull request to improve the extension in a lerna setup.

dbaeumer on 4 Sep 2019

In my real project I have more packages in the packages directory and I have been playing with the eslint.workingDirectories option. I've assumed that when I add more than 1 working directories then it will fail to work but after testing it right now I see that it works. Here is my .vscode/settings.json file.

{
  "eslint.enable": true,
  "eslint.packageManager": "yarn",
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    { "language": "typescript", "autoFix": true },
    { "language": "typescriptreact", "autoFix": true }
  ],
  "eslint.workingDirectories": [
    { "directory": "packages/app", "changeProcessCWD": true },
    { "directory": "packages/server", "changeProcessCWD": true }
  ]
}

I don't know why I've assumed that having 2 working directories will fail to detect tsconfig.json in each one.

I've also updated my reproduction to reflect that.

I'm actually happy with that. I will just push my .vscode/settings.json file to the repository. Maybe it's not perfect but it will work. The ideal solution would be to just detect, that it's Lerna repository and add these working directories "on the fly".

Thanks for the help :)

EDIT:
Haha funny thing is that I've just checked your vscode-eslint repository and you've actually pushed settings.json file with two working directories :) which is perfect example of what I was trying to achieve.

lukejagodzinski on 4 Sep 2019

👍1

Hi!

I have a similar setup. Here’s my story. I think it might be relevant to anyone migrating from TSLint to ESLint.

I regularly work on a repo that is a "master repo" to a bunch of micro services. The folder structure looks like this:

api/       -- random old stuff
serviceA/  -- git submodule to repo for serviceA
serviceB/  -- git submodule to repo for serviceB
serviceC/  -- git submodule to repo for serviceC
README.md
.gitmodules

In other words, each folder is its own service. They all use TypeScript and TSLint (yes, TSLint – I’ll get back to that), but with slightly different versions and configs. We try to update them to all use the same stuff as we work on different services, but you know, stuff changes all the time.

The easiest way to work on this project is to do it from the "master repo". I cd into the root of that repo and type code . to open VSCode. Then I can easily open any file from any service in one VSCode window. If I want to run command line tools (git, npm, tsc, tslint, etc), I first have to cd into the appropriate service folder, because each service is basically its own world with its own node_modules folder. A little annoying maybe, but that’s the way it is.

My experience with the TSLint plugin for VSCode is that it seems to Just Work. Even though I run VSCode from the "master repo" root, where tslint isn’t even installed, it still manages to lint all relevant files in all repos, with the correct configs and versions.

As we all know, TSLint is slowly being deprecated in favor of @typescript-eslint. I’m really excited about that, since it means that TypeScript users will get access to the wealth of ESLint plugins. But migrating to ESLint is a little painful to me, because as of right now my team kind of get worse UX in VSCode.

I think it would make sense to try to beat the TSLint plugin UX-wise!

While the TSLint plugin seems to work out of the box (the only difficult thing was to figure out how to enable autofix on save), vscode-eslint has so much stuff that everyone working on the project need to put in their .vscode/settings.json:

{
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    {"language": "typescript", "autoFix": true },
    {"language": "typescriptreact", "autoFix": true }
  ],
  "eslint.workingDirectories": [
     { "directory": "./api", "changeProcessCWD": true },
     { "directory": "./serviceA", "changeProcessCWD": true },
     { "directory": "./serviceB", "changeProcessCWD": true },
     { "directory": "./serviceC", "changeProcessCWD": true }
  ]
}

Would it make sense to change how vscode-eslint operates? Currently, it seems to operate on the assumption that all files can be linted from CWD. (The root of the "master repo" in my case.) Wouldn’t it be awesome if the plugin could automatically figure out the correct CWD, eslint binary and config to use for any given file?

I’m not sure if it helps at all, but elm-language-client-vscode seems to work this way. For example, it auto-detects that app/src/Main.elm uses the app/node_modules/.bin/elm binary for compilation and that it needs to run it in app/.

I have also worked on many projects that have a backend/ and a frontend/ folder. backend/ might be written in whatever language, frontend/ is written in JavaScript. Same thing there – it would be super nice if one could do code . in the repo root and linting inside frontend/ Just Worked.

Off-topic notes if you’re interested in more TSLint->ESLint stories :)

I haven’t felt like I’ve bumped into any issues with autofix in the TSLint plugin. But with vscode-eslint I regularly bump into #154.
If I open a project that does not use TSLint I simply get no TSLint in VSCode. With vscode-eslint I get an error message: #446

Thanks for reading and thanks for the plugin!

lydell on 19 Oct 2019

👍2

Hi!

Any update about this?

I have a similar mono repository structure and the same issue. Updating the 'eslint.workingDirectories' each time a new package is added to the repository is far from an optimal solution.

It would be nice if it were possible to configure the eslint vscode extension to automatically detect the location of packages (for example, locate thepackage.json file) and change the working directory to that location.