Use nearest package.json/node_modules to locate local eslint about vscode-eslint HOT 11 CLOSED

@ChuckPierce vscode does pick up the local eslint. The problem is that it only looks in the root of the project, but not in the nearest folder like atom does. This means that if my JS project is a child of a larger non-js (or non-eslint) project, then vscode doesn't even run eslint.

from vscode-eslint.

This is addressed in the upcoming 1.1.0 release of ESLint.

from vscode-eslint.

+1. This is another painful problem which is stopping me from using vscode in any serious way. Atom flawlessly picks up the correct eslintrc file and the nearest eslint package.

from vscode-eslint.

I tested that the plugin uses the nearest .eslintrc file. However it doesn't pick up the nearest eslint module. I need to think about what the consequences are. Currently we keep the one eslint checker active to avoid starting it over and over again. When we start to pick the nearest eslint module we would need to manage different eslint instances.

from vscode-eslint.

Hmm, yeah I hadn't thought of that yet... Although, in majority of the scenarios, a project would have one node_modules folder. I've not done any formal research, just applying my experience.

I myself have 2 more eslint instances nested within my project, but they are symlinked to the project-root-level, and also I required them only because my project has some fancy stuff with eslint (custom node-module for linting, etc).

Also, maybe taking a look at how Atom does it would be helpful.

from vscode-eslint.

Using the local eslint and the eslint plugins will solve a lot of the issues that are currently open on this extension. (anything that has the "Can't find eslint-plugin-")

With most editors out there, the eslint (as well as all of the eslint plugins such as eslint-plugin-react) is taken from the locally installed project. This allows for the users to use different eslint versions across different projects. Having to use a globally installed eslint or the locally installed eslint in the extension folder will limit the user to only one version of eslint (and its corresponding extensions).

Having the editor do this for you automatically is a big win and cuts down on unwanted error messages

from vscode-eslint.

@kumarharsh ahhh I see....hmm okay. I mean I suppose as long as I remember that it isn't too bad... The scenarios that you run into with this cases is basically any project that has a non-JS backend though. You just have to work in the folder that has the node_modules at its root

from vscode-eslint.

Yes, that is correct. And anyways, my project has grown too big to require a separate editor window for the frontend part, that's the reason why I'm not complaining loudly ;P

from vscode-eslint.

@dbaeumer any ideas about a fix for this? its one of the major pain points for me with using VS Code. Definitely willing to help.

from vscode-eslint.

@ChuckPierce finding the eslint npm module is currently static based on the workspace folder you have open and is done when the linter starts. Loading the closet eslint module would require the following changes:

• don't look up the eslint npm module on initialize
• when ask to validate a file, take the files path and try to locate the eslint npm module using the resolveModule function form the server npm module
• cache the result since the lookup is expensive.
• use the resolved eslint module
• come up with an error story when the resolving fails (e.g. the eslint module can't be resolved). Currently this is easy since we resolve statically at startup.

from vscode-eslint.

The code to look at is here: https://github.com/Microsoft/vscode-eslint/blob/master/eslint-server/src/server.ts

from vscode-eslint.