-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug?]: Yarn pnp / sdk generation doesn't work with ESLint new flat config support #6219
Comments
Any news on this. This issue is basically blocking flat config adaption with VS Code / eslint extension. |
I'm looking right now at migrating this repository to Eslint 9; I'll take a look at that at the same time. |
I'm experimenting in #6278 - it seems to work with your (very detailed, thanks a lot!) reproduction, but it still fails in VSCode. Trying to figure out what might be different. |
I think I figured it out - v18.19.0 is the first version that supports |
@arcanis thanks for looking into this. Which node version is required to make this work. I tested the same steps under Node 20.10.0 and it produces the same exception. |
You need both my PR (#6278) and Node >v20.6.0, v18.19.0; you can try it by cloning my branch and running your repro in this repo. |
Thanks! We will move to Electron 29 in the near future which will come with NodeJS 20.x |
@arcanis do you have any timeline when this will show up in |
I'd like to confirm it works before merging it - is there a vscode build with an up-to-date Node.js? |
The insiders build has updated to Electron 29 with Node 20.9 |
@clemyan thanks for point it out. @arcanis you can find the insider build here: https://code.visualstudio.com/insiders/ |
https://code.visualstudio.com/updates/v1_90#_electron-29-update
I can confirm this still won't work with the extension |
## What's the problem this PR addresses? ESM loaders aren't supported by the sdks because we only `require().setup()` but we don't `register()` the ESM loader hook. Fixes #6219 ## How did you fix it? - Add support for ESM loaders to the SDK. - Check whether the `findPnpApi` function could be found in the `module` builtin. If not, tries to setup the environment accordingly. This is because in the case of the SDK, the subprocesses have been created without the `--require .pnp.loader.mjs` flag, so the PnP runtime won't be setup. ## Checklist <!--- Don't worry if you miss something, chores are automatically tested. --> <!--- This checklist exists to help you remember doing the chores when you submit a PR. --> <!--- Put an `x` in all the boxes that apply. --> - [x] I have read the [Contributing Guide](https://yarnpkg.com/advanced/contributing). <!-- See https://yarnpkg.com/advanced/contributing#preparing-your-pr-to-be-released for more details. --> <!-- Check with `yarn version check` and fix with `yarn version check -i` --> - [x] I have set the packages that need to be released for my changes to be effective. <!-- The "Testing chores" workflow validates that your PR follows our guidelines. --> <!-- If it doesn't pass, click on it to see details as to what your PR might be missing. --> - [x] I will check that all automated PR checks pass before the PR gets reviewed.
I can confirm the same as @n0099. I still get
I debugged a little and it is still unable to find Maybe i am missing something in my setup? Happy to provide more info if needed 😊 |
Yes.
I've also tried using old extension
btw did you did |
No, i works with the 'plugged' version for me. |
I'm using |
I can reproduce this without the extension using the sdk version from #6278 and running
If i run the config through
UPDATE @n0099 Do not use |
@Sebbones I'm implementing this on Wednesday and I find your findings really helpful. There's a bit of clutter now, could I ask you what steps you'd suggest to correctly install this in a clean project? |
#6278 is already merged 4 days ago, so just running |
Is this not fixed yet? because I still have the same problem( |
Until a new version of
Steps: your_project_root=
git clone --filter=tree:0 https://github.com/yarnpkg/berry yarn
cd yarn
git checkout 0cef81fe1bdc35def2c6d0e88dd44a998707661c
yarn build:cli
cp packages/yarnpkg-cli/bundles/yarn.js $your_project_root/.yarn/releases/yarn-0cef81fe.js
cd $your_project_root
sed -i 's@yarnPath: .yarn/releases/yarn-4.2.2.cjs@yarnPath: .yarn/releases/yarn-0cef81fe.js@' .yarnrc.yml
yarn dlx @yarnpkg/sdks vscode Then I get #5831: Error: Dynamic require of "util" is not supported
at file:///.yarn/releases/yarn-0cef81fe.js:4:394
at file:///.yarn/releases/yarn-0cef81fe.js:4:3572
at file:///.yarn/releases/yarn-0cef81fe.js:4:478
at file:///.yarn/releases/yarn-0cef81fe.js:9:46377
at file:///.yarn/releases/yarn-0cef81fe.js:4:478
at file:///.yarn/releases/yarn-0cef81fe.js:392:1509
at file:///.yarn/releases/yarn-0cef81fe.js:735:11937
at ModuleJob.run (node:internal/modules/esm/module_job:262:25)
at async ModuleLoader.import (node:internal/modules/esm/loader:475:24)
at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:109:5) |
I just triggered a release. Using the 4.3.0 the original test case doesn't crash anymore. In case you still face issues, please make sure you use both Yarn 4.3 and the SDK 3.1.3. If you do, open a new thread (let's not reuse this one, I'd like to keep investigation separate as something that may look related may be a completely different bug). For reference, here's a script to easily run the commands from the op; note I updated #!/usr/bin/env bash
cd $(mktemp -d)
cat > package.json <<EOF
{
"name": "yarn-eslint-test",
"packageManager": "yarn@4.3.0",
"type": "module",
"scripts": {
"eslint": "eslint test.js"
},
"devDependencies": {
"@eslint/js": "^8.57.0",
"eslint": "^8.57.0"
}
}
EOF
cat > eslint.config.mjs <<EOF
import js from "@eslint/js";
export default [
js.configs.recommended,
{
files: ["**/*.js"],
rules: {
"no-var": "error",
}
}
];
EOF
cat > test.js <<EOF
var x = 10;
EOF
yarn install
yarn dlx @yarnpkg/sdks vscode
export NODE_PATH=".yarn/sdks"
node <<EOF
require.resolve('eslint');
const library = require('eslint');
async function main() { const eslint = new (await library.loadESLint({ useFlatConfig: true }))(); const report = await eslint.lintText('var test = "hello";'); console.log(report); }
main().catch((error) => { console.error(error); process.exitCode = 1; });
EOF |
$ yarn add -D @typescript-eslint/{parser,eslint-plugin}@npm:rc-v8 $ yarn dedupe $ yarn set version latest # fix yarnpkg/berry#6219 * remove `yarnPath` to prefer corepack @ .yarnrc.yml @ fe
$ yarn add -D @typescript-eslint/{parser,eslint-plugin}@npm:rc-v8 $ yarn dedupe $ yarn set version latest # fix yarnpkg/berry#6219 * remove `yarnPath` to prefer corepack @ .yarnrc.yml @ fe * run `corepack enable` to fix actions/setup-node#1027 @ .github/actions/fe/action.yml
@arcanis is this register behavior something that libraries are expected to implement when supporting PnP? Or should a |
In the past I think there was a vscode stylelint SDK. I don't see why not since the ecosystem supports it. But given of what we know, it seems fair to notify the plugin devs for a complete solution on their end. |
Sorry for posting on a closed thread, but may I know if ESLint flat config can work with Yarn v3 + VSCode? We use Node.js v18.20.4 with Yarn v3.8.4 + vscode-eslint 3.0.10, and our VSCode folks are seeing the error below on startup:
settings.json: {
"search.exclude": {
"**/.yarn": true,
"**/.pnp.*": true
},
"eslint.nodePath": ".yarn/sdks",
"prettier.prettierPath": ".yarn/sdks/prettier/index.cjs",
"typescript.tsdk": ".yarn/sdks/typescript/lib",
"typescript.enablePromptUseWorkspaceTsdk": true,
"eslint.useFlatConfig": true,
"eslint.runtime": "node"
} Personally I use LazyVim/mason + https://github.com/hrsh7th/vscode-langservers-extracted, and it's actually working perfectly for me. Now I'm puzzled about how we can get it working in VSCode too. Can someone give me a hand? Thanks! Edit: Our ESLint version is v9.10.0. |
@Frederick888 Based on #6219 (comment) , have you tired Yarn v4.3? |
@psychobolt Thanks for the reply! I have created a small reproducer here: https://github.com/Frederick888/playground/tree/eslint-yarn3
Yes, Yarn v4 did not have this issue (reproducer: https://github.com/Frederick888/playground/tree/eslint-yarn4), but due to [insert corporate reasons here lol], I'd like to stay on Yarn v3 if possible. So I'm just wondering if I can tell VSCode to work in the same way as vim does. |
@Frederick888 Using the v4.3 CLI will get the SDK's register loaded properly for ESLint, but that is missing in Prior, to v4.3 a workaround was passing the loader option to |
@psychobolt Thanks again for the pointer. I added the loader option {
"search.exclude": {
"**/.yarn": true,
"**/.pnp.*": true
},
"typescript.tsdk": ".yarn/sdks/typescript/lib",
"typescript.enablePromptUseWorkspaceTsdk": true,
"eslint.nodePath": ".yarn/sdks",
"eslint.useFlatConfig": true,
"eslint.runtime": "node",
"eslint.execArgv": [
"--loader",
"/path/to/playground/.pnp.loader.mjs"
],
"prettier.prettierPath": ".yarn/sdks/prettier/index.cjs"
} ...and now getting a slightly different error
|
Don't think the error is any different. Did you try an absolute path? |
Sorry I was talking about the error stack trace: the one after adding
Yes, I tried absolute path. (Relative path |
I think I found the solution, thanks to @psychobolt's hints. In addition to {
"search.exclude": {
"**/.yarn": true,
"**/.pnp.*": true
},
"typescript.tsdk": ".yarn/sdks/typescript/lib",
"typescript.enablePromptUseWorkspaceTsdk": true,
"eslint.nodePath": ".yarn/sdks",
"eslint.useFlatConfig": true,
"eslint.runtime": "node",
"eslint.execArgv": [
"--require",
"/home/frederick/Programming/Others/playground/.pnp.cjs", // relative path works under Linux (w/o sandboxes/containers like firejail, flatpak, etc., perhaps)
"--loader",
"file:///home/frederick/Programming/Others/playground/.pnp.loader.mjs" // relative path works under Linux, but needs to remove file:// cos file:// scheme doesn't support relative paths IIRC
],
"prettier.prettierPath": ".yarn/sdks/prettier/index.cjs"
} How I discovered this workaround: $ y node
Welcome to Node.js v22.9.0.
Type ".help" for more information.
> process.env.NODE_OPTIONS
'--require /home/frederick/Programming/Others/playground/.pnp.cjs --experimental-loader file:///home/frederick/Programming/Others/playground/.pnp.loader.mjs'
$ node --require /home/frederick/Programming/Others/playground/.pnp.cjs --loader file:///home/frederick/Programming/Others/playground/.pnp.loader.mjs
Welcome to Node.js v22.9.0.
Type ".help" for more information.
> require('@eslint/js')
{
configs: { all: { rules: [Object] }, recommended: { rules: [Object] } }
}
# --loader alone doesn't work
$ node --loader file:///home/frederick/Programming/Others/playground/.pnp.loader.mjs
Welcome to Node.js v22.9.0.
Type ".help" for more information.
> (node:359480) ExperimentalWarning: `--experimental-loader` may be removed in the future; instead use `register()`:
--import 'data:text/javascript,import { register } from "node:module"; import { pathToFileURL } from "node:url"; register("file%3A///home/frederick/Programming/Others/playground/.pnp.loader.mjs", pathToFileURL("./"));'
(Use `node --trace-warnings ...` to show where the warning was created)
> require('@eslint/js')
Uncaught Error: Cannot find module '@eslint/js'
Require stack:
- <repl>
at Module._resolveFilename (node:internal/modules/cjs/loader:1248:15)
at Module._load (node:internal/modules/cjs/loader:1074:27)
at TracingChannel.traceSync (node:diagnostics_channel:315:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:217:24)
at Module.require (node:internal/modules/cjs/loader:1339:12)
at require (node:internal/modules/helpers:135:16) {
code: 'MODULE_NOT_FOUND',
requireStack: [ '<repl>' ]
} PS: I probably confused myself somehow when I made the ' |
@Frederick888 Ah I forgot about the |
And just noticed that relative paths don't work on macOS either. And in fact I did not confuse myself, cos e.g. using |
Why is this issue closed? it's definitely still happening and I don't see a fix? I'm having issues of peer-dependencies between eslint and the parsers and updating to the latest version seemed to be the fix, but then I have these issues with yarn 3 and imports... |
Is there any solution? |
Quoting #6219 (comment):
|
Self-service
Describe the bug
ESLint's new flat config support fails to load when using flat config module files. It does work when using common JS config files.
This bahviour gor reported against the VS Code ESLint extension (see microsoft/vscode-eslint#1620) but it is independent of the VS Code extension and can be reproduce using the eslint npm package standalone
To reproduce
Setup:
package.json
eslint.config.mjs
test.js
Run the following commands in a shell:
Setting the NODE_PATH is equivalent to setting the VS Code eslint.nodePath setting.
start node REPL and execute the following commands (to ensure to mimic the executing since a VS Code extension):
We will load the eslint npm module from .yarn/sdks
You get:
Expected behavior: the eslint.config.mjs can successfully be loaded. Converting the config file to cjs makes everything work.
Environment
System:
OS: Linux 5.15 Ubuntu 22.04.4 LTS 22.04.4 LTS (Jammy Jellyfish)
CPU: (20) x64 12th Gen Intel(R) Core(TM) i7-12700K
Binaries:
Node: 18.18.2 - /tmp/xfs-e72dc863/node
Yarn: 4.1.1 - /tmp/xfs-e72dc863/yarn
npm: 9.8.1 - ~/.nvs/default/bin/npm
Additional context
No response
The text was updated successfully, but these errors were encountered: