Fails to load when XO is installed using yarn PnP

[huw]

Yarn Plug'n'play is a new feature developed by the yarn maintainers that changes how modules are resolved—XO is no longer found in node_modules and must be resolved using a custom resolver.

Steps to reproduce

1. Enable yarn plug'n'play
2. Install xo locally
3. Enable the XO extension

Error

We get a pretty standard error: "Failed to load XO library. Make sure XO is installed in your workspace folder using 'npm install xo' and then press Retry."

Recommended Fix

In Yarn v2, there is an automatic solution for this called pnpify. One could solve this by allowing the user to specify the path to the node executable in the settings for the plugin. pnpify can handle the rest by setting to node path to .vscode/pnpify—although submitting a PR there to have it automatically register and handle that would be helpful.

[shanoaice]

I took a look on the Yarn v2 docs, and I thought that we should use the Editor SDK, but XO is currently not on the supported tools list. I suppose that we should send a PR to add support of XO to the editor sdk, and then turn back to the extension side of supporting pnpify.

[sindresorhus]

I'm closing this as it's up to the Yarn team to resolve any incompatibilities with the existing community. Open an issue on Yarn about this or do:

I suppose that we should send a PR to add support of XO to the editor sdk, and then turn back to the extension side of supporting pnpify.

[flying-sheep]

What do I set "xo.runtime" to to make this work?

[flying-sheep]

Or xo.path. There seems to be no way to set it relative to the project directory

[shanoaice]

Yarn v2 (and its successor v3) uses a very non-standard way to store its modules, and all of its module resolution jobs is done by injecting .pnp.js and tinkering with Node's module resolution logic, so there is presumably no way to solve this problem by simply changing vscode-xo-linter's config.

My suggested solution will be switching to eslint-config-xo + ESLint VSCode plugin combo. The ESLint VSCode Extension currently supports Yarn's Editor SDK, so there will be no problem linting with Yarn v3 and PnP enabled (though you need to manually generate the Editor SDK).

Another resolution will be simply specifying nodeLinker: node-modules in the Yarn configuration to force Yarn to use the conventional way to organize dependencies so that no Editor SDK or other hassle is needed.

[flying-sheep]

non-standard way

Sorry for my pedantry, but there is no standard way to store modules. node_modules is a convention the tool npm introduced and has staying power only because of npms success.

I think it’s fair to develop alternative solutions that are superior for certain use cases.

so there is presumably no way to solve this problem by simply changing vscode-xo-linter's config.

I’m pretty sure the same solution as eslint would work:

1. (this extension) allow relative paths in xo.path so specifying e.g. file://${workspaceFolder}/.yarn/sdks/xo/lib/index.js or so would work.
2. (yarn) add the necessary setting and files to the yarn SDKs like for ESLint: https://github.com/yarnpkg/berry/blob/31738d08d289054e613d6d455e1db760ec4c978f/packages/yarnpkg-sdks/sources/sdks/vscode.ts#L32-L48
3. (this extension) relax the version check so e.g. a version like 0.46-sdk would be considered matching (optional, but it’s a bit annoying to update the SDK’s version string every time you update XO in yarn.lock)

[spence-s]

@flying-sheep curious why you can't just set the absolute path on your system? There is no "version check" that we do with this extension. We just load the version on startup so you can see that its using the right version, it doesn't actually do anything. If you use the path option, we don't check the version at all, we just call it "custom"...It should just work.

I do this when I work on xo itself, because i want to lint xo with xo in vscode:
My workspace options are:

"xo.path": "file:///users/spencer/projects/xo/index.js",

The startup in the extension logs look something like:

If you update the xo version while vscode is open - you will need to force vscode to recache the new xo version and its easiest to open the command palette and use "Developer: reload window"

As a side note: the "runtime" option is a path to the nodejs binary. I have that set in my user settings, and I recommend setting it so you are always running xo with the same version of node you're running in your terminal.

[flying-sheep]

I commit my project configuration and expect it to be self contained and machine independent.

I long ago stopped having absolute paths anywhere.

/edit: ah I see about the version stuff, I misinterpreted the code!