[rush] does not play nicely with VSCode ESLint plugin

[jasonswearingen]

Is this a feature or a bug?

• [ X] Bug

Please describe the actual behavior. extended .eslintrc.js usually breaks the VSCode ESLint plugin integration.

the VSCode ESLint plugin maintainer thinks it's because RushStack patches ESLint, as described here: https://github.com/microsoft/vscode-eslint/issues/1040

That may be true, however I have experienced where on linux, "extends": ["@rushstack/eslint-config", ], actually works (ESLint plugin works) but the same on windows doesn't work. see: https://github.com/microsoft/vscode-eslint/issues/1041

This may not be a RushStack issue, but maybe it is. So I'm linking these two external bugs in case you have some feedback/advice for the ESLint VSCode plugin maintainer.

What is the expected behavior? ESLint VSCode plugin doesn't stop working

If this is a bug, please provide the tool version, Node.js version, and OS.

• Tool: ESLint VSCode plugin v2,1,8
• Tool Version: Rush 5.30.2
• Node Version: 14.7.0 pre-lts
  • Is this a LTS version? nope
  • Have you tested on a LTS version? nope
• OS: Win10, and Ubuntu20.04 via WSL2

[jasonswearingen]

nevermind, this is a case of user error.

Though, the confusion comes from HEFT (not rush and/or pnpm as I originally thought) referencing some special version of eslint. see https://github.com/microsoft/vscode-eslint/issues/1041#issuecomment-670652081 for further explanation.

[octogonz]

@jasonswearingen Hmm... I use the ESLint extension for VS Code, and seems to work fine in Rush projects. I'll mention that I do /not/ open VS Code at the root of the monorepo. Instead, I open a separate instance of VS Code for each project folder. There are a couple reasons why I do this:

1. Some tools get confused because they don't understand monorepos
2. When working in a very large monorepo, the root folder exposes simply too many files, and IntelliSense becomes unreliable. This is simply the reality of a very large input size.

That said, if you are able to figure out how to repro this problem, I'm curious about it. Even if we cannot fix anything, we could at least document the limitations to help anyone else who may encounter it. Thanks!

[jasonswearingen]

@octogonz thanks for the advice. I'm really looking forward to trying out apiExtractor+Documentor once I get the rushstack basics figured out!

regarding the problem, it was simply because the @xlib/eslint-config project didn't have the various eslint dependencies installed. It seems that heft (not rush as I originally thought) has some internal reference to eslint so it doesn't mind in that situation, while the eslint cli tool or vscode-eslint uses the project eslint "properly" so they fail.

It took me so long to figure out the problem because vscode-eslint doesn't show any error messages and I was too much of a noob to try the eslint cli

[octogonz]

It seems that heft (not rush as I originally thought) has some internal reference to eslint so it doesn't mind in that situation, while the eslint cli tool or vscode-eslint uses the project eslint "properly" so they fail.

Heft doesn't directly depend on ESLint itself, but it has a more sophisticated way of discovering it. This is explained in the Centralizing dependencies in a rig package article.

It took me so long to figure out the problem because vscode-eslint doesn't show any error messages and I was too much of a noob to try the eslint cli

Ah, makes sense. Perhaps vscode-eslint could improve this.

[axelboc]

I'm currently running into this issue. I'm trying to use ESLint directly, not through Heft, and with a shared config called eslint-config-galex.

I have a project at /packages/lib with a package.json of the form:

{
  "scripts": {
    "lint": "eslint \"**/*.{ts,tsx}\""
  },
  "devDependencies": {
    "eslint": "^7.32.0",
    "eslint-config-galex": "^2.16.11"
  }
}

... and an .eslintrc.js file of the form:

const { createConfig } = require('eslint-config-galex/src/createConfig');

// `cwd` lets Galex find `package.json`, which it reads to determine my project's deps (React/TypeScript/etc.)
module.exports = createConfig({ cwd: __dirname });

When I run rushx eslint, everything works great, but the linting integration in VSCode doesn't work. The debug output of my ESLint extension (dbaeumer.vscode-eslint) is as follows:

[Info  - 10:03:33 AM] Failed to load plugin 'import' declared in 'packages\lib\.eslintrc.js':
Cannot find module 'eslint-plugin-import' 
Require stack: - C:\Users\...\packages\lib\__placeholder__.js

When I look in /packages/lib/node_modules, I only see eslint and eslint-config-galex, as expected, but when I look in /packages/lib/node_modules/eslint-config-galex/node_modules, I only see a .bin folder -- none of Galex' dependencies seem to be symlinked to their installation location in /common/temp/node_modules.

Is this normal behaviour and is there a way to work around it (other than installing every child dependency of Galex in my own project, which defeats the purpose of using a shared config)?

[Darksoulsong]

Same issue as @axelboc here. I created a package to centralize eslint settings for all my apps and rushx lint & rush lint works as they should, but vscode simply doesn't show me any errors.

The workaround mentioned by @octogonz does not work either.

[andykao1213]

Having same issue as @axelboc . And I also cannot fix the issue by opening a single package with VSCode as @octogonz suggest. Would like to know any update on this.

[itpropro]

I have the same problem currently. As soon as you reference an external package in your .eslintrc (or any other eslint config file), the VSCode extension stops working with Cannot find module 'eslint-plugin-import'.

Can you please reopen this issue @octogonz, as others also seems to have this problem and there is no solution provided currently?

EDIT: In case anyone comes across this issue, the problem is in eslint itself. The rushstack team created a patch for eslint as separate package, as the eslint maintainers didn't want to accept the fix in their main branch: @rushstack/eslint-patch. You have to use a .eslintrc.js file and can then use the patch module resolution like this:

require("@rushstack/eslint-patch/modern-module-resolution");

// Add your "extends" boilerplate here, for example:
module.exports = {
  extends: ['@your-company/eslint-config'],
  parserOptions: { tsconfigRootDir: __dirname }
};

https://www.npmjs.com/package/@rushstack/eslint-patch