// @Richienb

There's no way to provide the absolute path of a plugin so I'm not quite sure how to fix it. The issue appears to have been present before xo 0.40.0 but Error: Failed to load config "xo" to extend from. would be thrown before it had a chance to be handled.

Perhaps it could be possible to set the cwd to a directory that can resolve the plugins and then compute the absolute paths of everything else but that would be opening a can of worms.

eslint/eslint#6237

Is this happening because I'm installing xo globally? I'm sorry to report these problems :( I already have an eslint setup in my project directory so I thought installing xo globally (like in the docs) would allow me to try it.

Is this happening because I'm installing xo globally?

It is very likely the case. Try a local installation and see if it works.

I had this problem and a local install of xo fixed it

I'll try it, it's just that I already have eslint and some plugins installed, and I'm worried that something's going to get messed up :(

@AndrewMSHowe Can you try running $ npx xo in your project?

@Richienb Maybe we could detect this case and add a human-friendly error message?

OK weird so that asked me to install xo, and it has apparently put it somewhere other than global or in my project. It doesn't work because of some docker stuff that's mapped into my project folder. I would have to find a way around that. If I run it from a subdir with just source, it gives the same error about plugin 'ava' (I'm not using ava, but I guess it wants to load the plugin anyway). This time the error is Error: Failed to load plugin 'ava' declared in 'BaseConfig » /home/andrew/.npm/_npx/5b73490bd3e0c08a/node_modules/xo/config/plugins.js': Cannot find module 'eslint-plugin-ava' so I guess ~/.npm/_npx is where it ended up.
If you add an error message for global and npx usage then you will want to remove the --global from the Install section in the readme.md...

Sorry I guess I need "npx xo" for local usage when I have installed xo locally rather than letting npx install it in its own stash, so that may have been misleading above.

Anyway it does work locally, although I'm not sure how I will get it to work automatically in VSCode as well as my current setup.

Just discovered the resolvePluginsRelativeTo option which should be able to fix this. PR incoming soon.

<gentle nudge> this stuff is also holding up the vscode plugin. Did you get anywhere with your PR?

As it turns out, fixing this problem causes another one to occur which has led me to conclude that resolvePluginsRelativeTo is not the solution.

Would you be able to elaborate what other problem it causes? For posterity.

The option doesn't let you specify multiple directories to resolve plugins from so that it would be possible to specify the node_modules where xo is installed and the node_modules of the current working directory at the same time.

Because it is also not possible to provide absolute paths as plugins, I don't see any good way to do this.

@Richienb Thanks for elaborating. It's seems we have hit a dead-end... Maybe it's worth opening an ESLint issue with a proposal with an option/API that could resolve this issue.

eslint/eslint#6237

@Richienb I didn't see you comment above before I send #589, can you explain what case won't work with the resolvePluginsRelativeTo option?

Did you mean install xo in a parent dir and install another plugin in a child dir, and run from child dir?

@Richienb I didn't see you comment above before I send #589, can you explain what case won't work with the resolvePluginsRelativeTo option?

When xo could still be installed globally, it was not possible to reference plugins from both the node_modules of xo and the node_modules of the project at hand. However, since xo removed global installation support, this might no longer be a problem.

Right, thanks.