microsoft/rushstack

[rush] eslint command in rush autoinstallers broken after updated the rush and pnpm version

Closed this issue · 5 comments

Summary

I am using the rush custom command with autoinstallers to run eslint check, and all the eslint plugin packages was installed in the autoinstallers. Everything works fine. But after I updated the rush and pnpm version, I got this error:

Oops! Something went wrong! :(
ESLint: 7.32.0
ESLint couldn't find the plugin "eslint-plugin-react".
(The package "eslint-plugin-react" was not found when loaded as a Node module from the directory "D:\project\frontend\packages\my-component".)

Details

I found the error was caused by the changes at node_modules/.bin/eslint file, which had some differences in the value of NODE_PATH.

#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")

case `uname` in
    *CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac

if [ -z "$NODE_PATH" ]; then
  export NODE_PATH="xxx"
else
  export NODE_PATH="xxx:$NODE_PATH"
fi
if [ -x "$basedir/node" ]; then
  exec "$basedir/node"  "$basedir/../eslint/bin/eslint.js" "$@"
else
  exec node  "$basedir/../eslint/bin/eslint.js" "$@"
fi

The differences are below the picture:
image

We can set the paths are less than before, which the path /mnt/d/project/frontend/common/autoinstallers/rush-lint/node_modules that actually works.

I don't know why there are these differences after update the rush, and I don't know how to fix it. But I find this issue microsoft/vscode-eslint#1040 (comment) said that maybe some tool (maybe rush?) patches this.

PS: I had tried using @rushstack/eslint-patch/modern-module-resolution, but also not works.

Standard questions

Please answer these questions to help us investigate your issue more quickly:

Question Before update After update
@microsoft/rush globally installed version? 5.54.0 5.109.1
rushVersion from rush.json? 5.54.0 5.109.1
useWorkspaces from rush.json? false true
Operating system? Windows Windows
Would you consider contributing a PR? No No
Node.js version (node -v)? 14.19.3 18.18.0
Pnpm version? 6.7.1 8.7.6

I have a similar issue but with a bit different backstory:

I reference the local dependency (Dep A) in autoinstaller via link: protocol and I want the dependencies of the Dep A to be installed by auto-installer so the Dep A can use them. ( I could've done it with rush update or rush install --only Dep A but this is much slower).

Dep A exposes a binary and I can see that the NODE_PATH in binary does not include the auto-installer's node_modules, only .pnpm virtual store: autoinstaller/<name>/node_modules/.pnpm/node_modules. So if I run the autoinstaller's CLI command it fails to find the dependencies.

I can manually set NODE_PATH env var to point to autoinstaller's node_modules which works but I'm not sure if it's a proper fix

I have a similar issue but with a bit different backstory:

I reference the local dependency (Dep A) in autoinstaller via link: protocol and I want the dependencies of the Dep A to be installed by auto-installer so the Dep A can use them. ( I could've done it with rush update or rush install --only Dep A but this is much slower).

Dep A exposes a binary and I can see that the NODE_PATH in binary does not include the auto-installer's node_modules, only .pnpm virtual store: autoinstaller/<name>/node_modules/.pnpm/node_modules. So if I run the autoinstaller's CLI command it fails to find the dependencies.

I can manually set NODE_PATH env var to point to autoinstaller's node_modules which works but I'm not sure if it's a proper fix

Before someone answers this issue, I temporarily created a patch script to add the correct path into NODE_PATH, and running this script each time before running the eslint command as a workaround.

I have a similar issue but with a bit different backstory:
I reference the local dependency (Dep A) in autoinstaller via link: protocol and I want the dependencies of the Dep A to be installed by auto-installer so the Dep A can use them. ( I could've done it with rush update or rush install --only Dep A but this is much slower).
Dep A exposes a binary and I can see that the NODE_PATH in binary does not include the auto-installer's node_modules, only .pnpm virtual store: autoinstaller/<name>/node_modules/.pnpm/node_modules. So if I run the autoinstaller's CLI command it fails to find the dependencies.
I can manually set NODE_PATH env var to point to autoinstaller's node_modules which works but I'm not sure if it's a proper fix

Before someone answers this issue, I temporarily created a patch script to add the correct path into NODE_PATH, and running this script each time before running the eslint command as a workaround.

My current fix is to set the NODE_PATH in command-line.json -> shellCommand, where autoinstaller's CLI command is defined:

        {
            "name": "<command-name>",
            "commandKind": "global",
            "summary": "Utility cli",
            "autoinstallerName": "<autoinstaller-name>",
            "safeForSimultaneousRushProcesses": true,
            "shellCommand": "NODE_PATH=$(pwd)/common/autoinstallers/<autoinstaller-name>/node_modules <command-name>"
        }

Having the same problem, but for the eslint plugin in vscode.

  • I have tested with a few version of pnpm8, from 8.0.0 to latest, all have the same behaviour
  • Copying the correct path into node_modules/.bin/eslint as described above fixes the linting (shows errors and warnings, formats on save), but the eslint server still exits with an error if you check it by clicking on the output tab in vscode
  • Error does not occur in pnpm7

Will update this message if I discover anything else.

Edit: running rush purge && rush update --full seems to have fixed it 🤷

This seems to be a pnpm issue. I'd recommend opening an issue for pnpm (here https://github.com/pnpm/pnpm). Is suspect it's leaving bin files around during an upgrade from pnpm 7 to pnpm 8, and it should be recreating them. Running rush purge should fix the issue.