I'm excited to use this extension. I'm on [email protected] and [email protected].
I have a somewhat unusual setup where eslint is brought in by a larger static analysis package that I've built. My dep tree looks like this:
root-package
└─┬ static-analysis-tool
└── eslint
When running from root-package, I get the following error message:
Failed to load eslint library. Please install eslint in your workspace folder using 'npm install eslint' or globally using 'npm install -g eslint' and then press Retry.
I would like to solve this by adding an option in the user preferences file to point vscode-eslint to the correct eslint location. This would be similar to how I can use the typescript.tsdk option to tell VSCode which TypeScript package to use.
This would also be useful for using VSCode to develop eslint itself. In that case, you'd want to use the eslint in the cwd.
I'd be happy to send a PR for this if you're amenable to it.
Thanks!
Related:
A PR for this is welcome.
I have a similar (but different enough) problem that maybe could benefit from a common solution.
My project is structured as a monorepo with two sub-projects that I work on concurrently - backend platform and client app. Both sub-projects use JavaScript, but with different babel transforms and eslint configurations (the client app has some additional transforms, that for various reasons means it can't share a common configuration for babel or eslint).
This structure seems to work fine with Atom and its eslint extension, but doesn't work with VSCode and its plugin. I'm not about to restructure my entire project just to support a code editor, so ideally the fix comes from here.
My suggestion is to create eslint instances based on the presence of an .eslintrc file. So if a project has two, you create two instances. You'd locate the binary based the location of configuration file. If you have nested configs (not super uncommon), you'd traverse up the file tree until you find the parent (or root) config.
@NickHeiner Any progress on this? :)
OK. With Eslint 1.0.x I will now look up the parent tree. In addition you can use the nodePath setting to point to a specific location where node should look for node_modules.
Most helpful comment
I have a similar (but different enough) problem that maybe could benefit from a common solution.
My project is structured as a monorepo with two sub-projects that I work on concurrently - backend platform and client app. Both sub-projects use JavaScript, but with different babel transforms and eslint configurations (the client app has some additional transforms, that for various reasons means it can't share a common configuration for babel or eslint).
This structure seems to work fine with Atom and its eslint extension, but doesn't work with VSCode and its plugin. I'm not about to restructure my entire project just to support a code editor, so ideally the fix comes from here.
My suggestion is to create eslint instances based on the presence of an .eslintrc file. So if a project has two, you create two instances. You'd locate the binary based the location of configuration file. If you have nested configs (not super uncommon), you'd traverse up the file tree until you find the parent (or root) config.