Add option for project level diagnostics

[i328638]

No description provided.

[msftclas]

All CLA requirements met.

[dbaeumer]

@i328638 thanks a lot for the PR. I looked at it and I think project level diagnostics would be cool for ESLint. However they way it is implemented will not scale very good since you read all files into memory (and this even happens sync) on server start.

The ESLint API offers to validate files using a path. It even offers wild card support. So if we implement such a feature it should make used of the ESLint API. In addition VS Code settings like files.exclude might be worthy to be honored.

[i328638]

@dbaeumer ,
I have changed my implementation to use the ESlint Api method- executeOnFiles. please review.

Can you please give me some more information of the files.exclude settings?

[dbaeumer]

I looked at the code and we should clearly separate project validation from single file navigation. For example the setting validateProject should not be a TextDocumentSettings since it is a global setting. And the triggering of a project validation shouldn't be faked as a TextDocument validation.

Here is how I as a user would expect project validation to work:

• if enabled all file in my project should be validated
• if I have 100s of file project validation should not bring my machine to a halt. The user still needs to be able to sufficiently type in VS Code.
• the files I type in have preference over project validation. Errors in these files should not be delayed by a project validation run
• project validation should re-run if configuration file or ESLint settings change. However this needs to be detected careful since project validation runs are expensive.

Can you check your implementation how it will behave in the above user scenarios.

The setting I was referring is files.exclude

[amiramw]

maybe the file name should be exactly .eslintrc and not contain

[dbaeumer]

In addition I noticed lately that ESLint does some cross file checking on imports. This complicates things a lot for proper project validation since we would need to build a dependency graph to proper solve this efficiently on typing.

[amiramw]

@dbaeumer does it mean that eslint LSP shouldn't be considered as a single file anymore but as a language with project system?

[dbaeumer]

@amiramw yes that would be the consequence.

[feedthejim]

Hi, any updates on the PR?

[i328638]

Hi,
I am interested to know if there are any updates regarding my recent pull request.
Could you please let me know if there are any changes I could implement to improve the code if needed.
In addition, I would like to know if there has been any progress with your implementation on this issue.

Thanks,
Naama

[dbaeumer]

There are a couple of things that have changed which we need to take into consideration

• the plugin contributes a task which basically validates the content of a workspace folder. This can be enabled via: "eslint.provideLintTask": true. The nice thing about the task is that it provides textual output as well which is available in the terminal. The downside is that it can never capture eslint fixes. So these two things look conflicting and I am not sure which I would prefer. Opinions ?
• the eslint server is now multi workspace folder aware, however the PR only handles one project folder. Since the server receives the workspace folders it should use those as a project URI and validate those for which project validation is enabled (you basically have to get the configuration for the workspace folder)
• I know that ESLint now also detects cross file issues. For example file A.js import B and B doesn't exist. If the user creates B a project validation should re-lint A to make the problem go away. But I have to say I never looked when ESLint now has API to determine that A as to be re-linted based on changes in B. @i328638 do you know this?

[dbaeumer]

I will close the PR since it doesn't have any traction. Please ping if you want to continue working on this.