Vscode-eslint: Popups with every folder I open

[kasvtv]

With every project folder that I open in VScode (File > Open folder...) I get the following popup:

"The eslint extension will use the eslint library node_modules/eslint installed locally to the workspace folder 'reponame' for validation. Do you allow this?"

This is really annoying and when the popup window is just closed without giving permission, ESlint will not load at all. This is a huge problem, because it was already hard enough to have teammates respect a linter, let alone when an annoying unexpected popup occurs that one is likely to dismiss, which will not make it load at all.

Is there anything regarding project configuration that will prevent this popup from occurring and just make ESlint work by default like it always did?

[spersico]

I'm seeing this too since yesterday, and I didn't change anything, though yesterday VSCode updated itself so it could be a VSCode problem.
I'm using WSL2 Ubuntu 20.04.

[TurboLion]

I saw this popup after VS Code updated to version 1.47.1 and I clicked on "Allow"; after that I had a couple weird bugs with auto-import not working in a React project, not sure if this is related to the popup or not.

[Lightfire228]

Probably related to the security patch 1.47.1 for vscode

The MS CVE says

An elevation of privilege vulnerability exists in Visual Studio and Visual Studio Code when they load software dependencies. ...

So I'd imagine that popup is related to the change in how external dependencies are loaded

[chrisdias]

@Lightfire228 that is correct, both VS Code and the ESLint extensions were updated yesterday.

Suggestion: Improve the message to make it more clear, such as:

The ESLint extension found the eslint executable in node_modules/eslint. If you trust this version of eslint, press OK. For more information, please see [link to a doc].

With the following options:

[Ok] [Cancel] [Don't Show Again]

//cc @kieferrm @misolori

[eamodio]

Alternate suggestion:

The ESLint extension will use the node_modules/eslint version of ESLint for validation, which installed locally to the workspace folder folder-name. If you trust this version of ESLint, press Allow. Otherwise, press Disallow, to disable ESLint for the workspace folder folder-name, or Cancel, to disable ESLint just for this session.

[Allow] [Disallow] [Cancel]

[spersico]

The most important thing to me, is to have a flag that always allows eslint to be run for the entire workspace, or globaly. Because, for some reason, VSC showed me this message inside of the same workspace like a hundred times today 😞

[chrisdias]

are you pressing Cancel each time, or Yes or No?

[spersico]

The first time, I pressed yes, and it kept opening when I changed files.
Then, after a few restarts of VSC, I pressed no, and still, it kept opening, same behaviour.
With cancel, same behaviour.
At some point, I pressed Yes, and the error went away, and it started working properly.

On Jul 15 2020, at 7:22 pm, Chris Dias [e-mail] wrote:
>
>

are you pressing Cancel each time, or Yes or No?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (https://link.getmailspring.com/link/[email protected]/0?redirect=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvscode-eslint%2Fissues%2F1012%23issuecomment-659045027&recipient=cmVwbHkrQUNRRURUUDI1NDNKV0IzWEdWSFNaRDU1RE5SSkRFVkJOSEhDT0xXS1Y0QHJlcGx5LmdpdGh1Yi5jb20%3D), or unsubscribe (https://link.getmailspring.com/link/[email protected]/1?redirect=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACQEDTLBVYH6FLS7FNZWF73R3YTZDANCNFSM4O2SIYMQ&recipient=cmVwbHkrQUNRRURUUDI1NDNKV0IzWEdWSFNaRDU1RE5SSkRFVkJOSEhDT0xXS1Y0QHJlcGx5LmdpdGh1Yi5jb20%3D).

[kieferrm]

Changed the buttons to 'Allow' and 'Do Not Allow' and the message to

The ESLint extension will use '${relativePath}' for validation, which is installed locally in '${folder.name}'. If you trust this version of ESLint, press 'Allow', otherwise press 'Do Not Allow'. Press 'Cancel' to disable ESLint for this session.

There was also a bug that caused the confirmation dialog to pop up for all open editors when the user did not trust the local version and answered with 'No' (now 'Do Not Allow'). I suspect that this is what @spersico has experienced.

[kieferrm]

@kasvtv we can't introduce a project setting here. The scenario the change is addressing is
1) You clone a repo, for example from GH, that has node_modules/eslint checked in, and then you open a file that eslint checks in VS Code
2) You download a zip of a repo, for example from GH, that contains node_modules/eslint inside, you unzip, and then you open a file that eslint checks in VS Code

[sarahsga]

I chose "Allow" every time this popup appeared, and now my auto-format on save has stopped working!

[s-h-a-d-o-w]

I think there should be a global setting to completely disable this behavior. It should be possible for a user to choose comfort over security, since there are probably many who don't use random eslint installations but always get them from npmjs.

[rjgotten]

@kieferrm
we can't introduce a project setting here. The scenario the change is addressing is (...)

Be that as it may, the entire thing is still a major annoyance and there are better solutions possible that choose a mid-road between (overly) stringent security and comfort.

A very simple one is to put the user in control and allow them to opt-out of this behavior by turning it off.
A more involved one would reduce the amount of times the prompt appears by comparing the installed eslint module against a set of known integrity hashes, instead of making it an explicit per-folder choice.

[coreyward]

@kieferrm I do not have node_modules under SCM and the dependencies were installed via yarn (not an unzipped project repo), but this still shows for me in every relevant project. I suspect something is wrong with the source tracking.

[tgreen7]

How about an "Always Allow" option? Or at least a setting that we can configure to disable this popup?

[andygock]

Having a config setting to "always use local install ESLint for validation when available" would be a good option. Having a interactive popup interrupting the user for every single project that is opened isn't great.

[dbaeumer]

Regarding some of the suggestions:

• always using a global installed ESLint version is not possible of all the version differences that exists. On top older ESLint version are very sensitive to loading plugins depending on whether ESLint is loaded globally or locally.
• detecting how the local ESLint version came on disk is very hard and might lead to problems as well. Simply the fact that it was not under Git doesn't mean it came via npm install.
• using hash codes to trust certain versions can easily fail with .eslintrc.js files and plugins.

[rjgotten]

using hash codes to trust certain versions can easily fail with .eslintrc.js files and plugins.

And this is in truth no different when looking at the scenario where a prompt explicitly asks you to trust a version of ESLint installed in a particular folder. Trusting that installation of ESLint does not and should not make a plugin referenced via an .eslintrc.js file implicitly trust-worthy either.

Even if you'd use a global installed ESLint, an ESLint plugin loaded via an .eslintrc.js config file can still come from any number of untrusted locations - including a folder within a repository downloaded as source code. In fact, you don't even have to look at plugins, as the .eslintrc.js is a JavaScript file and can require and run whatever the hell it wants.

In conclusion, the premise that adding this popup dialog offers _any_ kind of additional security is flawed to begin with.
And thus only the UX downside of having to click "Allow" each time remains.

[dbaeumer]

I will update the message to make this more clear.

[jsejcksn]

@dbaeumer When we select "Allow" or "Deny" in this dialog for each workspace: Where are our preferences being stored?

[dbaeumer]

@jsejcksn in a scoped store that the VS Code API provides to me.

[rjgotten]

I will update the message to make this more clear.

Just to get this straight: you're going to point out in the popup-message that you're pestering the user for a net zero gain in actual security, unless they vet the whole folder / workspace?

Over just axing the feature because it's effectively useless to prevent what you set out to prevent with it, because it's a UX nightmare and everyone will end up just clicking on "Agree" / "Allow" ? Or atleast offering an option to turn it _off_?

Ok then...

[dbaeumer]

IMO the right solution is to have something like a trusted workspace in VS Code itself which would make the whole concept more first class and will for example allow to trust certain GitHub URLs as well (e.g. trust every repository under https://github.com/myOrg like VS Code does for browser URLs). I have cycled that back to the corresponding devs in the VS Code team.

[rjgotten]

I was just going to point out as well that having either a workspace-level sandbox or a concept of 'scoped trust' / trusted scope' would be the way to truly solve this.
Hope to see the VS Code team respond to that.

[jsejcksn]

@dbaeumer I understand that there might be some discussion involved to make a decision about how to address this. Perhaps right now, you can switch from a blocking modal dialog to something like vscode.window.showInformationMessage or vscode.window.showWarningMessage with selectable options in the notification. This would be more in line with the expected behavior of other extensions and wouldn't force the user to select an option to be able to use the workspace.

[rjgotten]

@jsejcksn
Perhaps right now, you can switch from a blocking modal dialog

Using non-blocking notifications presents a different problem though: too easy for developers to forget to allow the linter to run and they'll work without feedback, only to be confronted with a pile-on of linting violations when e.g. a commit hook enforces linting conformation.

[jsejcksn]

@rjgotten A developer's ignoring notifications is a kind of personal issue, not one specific to this or any other extension.

No modal should ever disrupt interactions which are not directly related to the purpose of the modal.

This is a case where a modal dialog is inappropriate.

[spersico]

These are, IMO the best approachs:

• a global setting so that VSCode doesn't show me any message related to plugins running from any local project.
• a per-workspace setting, so that VSCode doesn't show me any message related to plugins running from this local project.
• Clear up the wording in the modal dialog, it's not clear what's happening, nor what's the result of pressing each button.
• I assume that what happened with my VSC was a bug (asking again and a again abut eslint, no matter what choice I selected), it no longer happens. I assume that when I rebooted my PC it magically fixed itself. But it shouldn't have happened, I'm not sure how you could be able to replicate the issue though.

[jjensen-ebsco]

How do we unset or change whatever setting the popup sets? I'm now getting errors for every single carriage return in my code.

[andygock]

@jjensen-ebsco As a workaround, until this gets resolved, you can right click on the extension and select "Install Another Version...", version 2.1.6 seems to not have this focus stealing popup issue. Reload/restart required.

[dbaeumer]

@jjensen-ebsco this is very likely unrelated to the dialog since it doesn't change any of the ESLint rules.

To manage the saved premissions run the following command ESLint: Reset Library Decisions

[chenchenwuai]

With every project folder that I open in VScode (File > Open folder...) I get the following popup:

"The eslint extension will use the eslint library node_modules/eslint installed locally to the workspace folder 'reponame' for validation. Do you allow this?"

This is really annoying and when the popup window is just closed without giving permission, ESlint will not load at all. This is a huge problem, because it was already hard enough to have teammates respect a linter, let alone when an annoying unexpected popup occurs that one is likely to dismiss, which will not make it load at all.

Is there anything regarding project configuration that will prevent this popup from occurring and just make ESlint work by default like it always did?

Downgrade eslint to version 2.1.4

[chenbingchang]

每次出现此弹出窗口时，我都选择“允许”，现在保存时我的自动格式已停止工作！

I choose "not allowed". Now my auto format has stopped working when saving!

[dbaeumer]

@chenbingchang this is expected. If you don't allow the extension to load the ESLint library auto format will not work either.

[OriAmir]

How could I change my decision ? in mistake I clicked "now allowed" and then it's stop to show me eslint errors on the editor.
I have to downgrade a version of the extension to make it work, the question if we could change the popup decision?

[waynebloss]

How does one make an educated decision on whether to trust one projects node_modules/eslint over another?

Otherwise - I'm pretty much always going to trust eslint unless I read some news about a security breach in the published package.

[dbaeumer]

@OriAmir To manage the saved permissions run the following command ESLint: Reset Library Decisions

[rjgotten]

How does one make an educated decision on whether to trust one projects node_modules/eslint over another?

One typically doesn't. It's not just eslint which needs to be trustworthy. It's also all its dependencies ; any plugins loaded via an .eslintrc.js file; _and_ their dependencies. The average ESLint user is not going to vet their entire package tree. They're just going to do what you're planning to do:

Otherwise - I'm pretty much always going to trust eslint unless I read some news about a security breach in the published package.

And that's why the existence of this dialog is bad. It trains users to just hit "Allow" and go on with their work.

[amirhoseinsalehi]

How could I change my decision ? in mistake I clicked "now allowed" and then it's stop to show me eslint errors on the editor.
I have to downgrade a version of the extension to make it work, the question if we could change the popup decision?

click on 'ESLint' on downside of vscode and next a popup shows to you and you can reset all eslint settings. :)

[MagicHacker]

so, what's the best solution?

[ryanblock]

@dbaeumer sorry if I missed it, but I've been following this thread and I'm still unclear: will the maintainers of this project be handling this issue? If so, specifically how?

[dbaeumer]

I had longer discussion with the VS Code team about this and there will soon be work happening for a a trusted workspace concept in VS Code itself which the ESLint extension will then adapt to. If a workspace is trusted there will be no need for ESLint to confirm execution.

[ryanblock]

@dbaeumer that's dope! In the mean time will y'all consider rolling this back until this trusted workspace feature ships?

[dbaeumer]

Just to ensure there is not another bug with the dialog. You should only see the dialog once per workspace folder / global install unless you close the dialog with Cancel or Escape.

[jsejcksn]

@dbaeumer If the workspace is not trusted, a blocking modal dialog is still a problem. Did you see my previous suggestion? https://github.com/microsoft/vscode-eslint/issues/1012#issuecomment-660949644

[samselikoff]

This dialog is very costly, as most users who encounter a blocking dialog not triggered by an action they took will take the default action to dismiss it. A blocking dialog is absolutely inappropriate here and I really wish it could get rolled back before the larger "trusted workspace" feature lands!

Also

you should only see the dialog once per workspace folder

is not relevant for those of us who work with many different projects (often OSS) throughout the week.

The dialog is really obnoxious and based on the actual way devs are using it, the benefits don't justify it at all!

At the least, please give us an option to globally approve the ESLint extension to use whatever binary it finds in any project.

[dbaeumer]

@jsejcksn the problem here is that VS Code doesn't offer any API to make the notification sticky meaning that the dialog will go away after n seconds making it easy to miss it. That would mean that ESLint will stay disabled with all the problems that will lead to.

[ryanblock]

As I asked before: in the mean time will y'all consider rolling this back until the trusted workspace feature ships?

[jsejcksn]

@dbaeumer

the dialog will go away after n seconds making it easy to miss it

VS Code provides a persistent symbol for unread notifications:

_Unread notifications:_

_No notifications:_

That would mean that ESLint will stay disabled with all the problems that will lead to.

Isn't that the entire purpose of this behavior change: not enabling ESLint without explicit user approval?

I'll quote myself from earlier in this discussion:

A developer's ignoring notifications is a kind of personal issue, not one specific to this or any other extension.

No modal should ever disrupt interactions which are not directly related to the purpose of the modal.

This is a case where a modal dialog is inappropriate.

The current behavior is hostile to users.

[dbaeumer]

Isn't that the entire purpose of this behavior change: not enabling ESLint without explicit user approval?

Yes, but if it is easy to be overlooked I think it is not good either. It will result in lots of user having ESLint being disabled without knowing it. The good thing about having a trusted workspace concept in VS Code itself will make it a lot easier to come up with a good UI since the solution will not be bound to VS Code API capabilities.

[jsejcksn]

Yes, but if it is easy to be overlooked I think it is not good either. It will result in lots of user having ESLint being disabled without knowing it.

This is your opinion (and I'm not saying it's necessarily wrong—it depends on how "lots" is defined), but it's hostile to everyone to continue to use a blocking dialog just because a subset of people don't pay attention to their notifications. That's their own problem, not everyone else's.

[bluepnume]

Yep, for now can we please get a configuration setting to always allow this?

[liby]

What I want to know is that if I choose to Allow: when I open a workspace, the ESlint version of the project may be different from the global installation. Which one has a higher priority? @dbaeumer

[chaddjohnson]

It would be really nice if this didn't pop up every single time I open a file. It's super annoying. A setting or button to globally allow is needed.

[dbaeumer]

@liby the one in the workspace folder wins over a globally installed one.

@bluepnume and @chaddjohnson I am working with the VS Code team on something that gives you more global control about this. If something like always allow is enabled it must be properly reflected in the user interface and this is best done in VS Code and not by the extension itself.

@chaddjohnson this should only happen once for a workspace folder you open (unless you press Escape). If you see that happening differently can you please provide me with steps on how to reproduce.

[horidon]

Hi all, accidentally chose disallow option for my directory in this pop up.
Is there any way to show this pop up again or remove a directory from ignore list?
Where does the ignore list with directories can be located?

[dbaeumer]

@Balashov-nikita yes, run the command ESLint: Reset Library Decisions

[horidon]

@dbaeumer Thank you!

[dinofx]

I opened a workspace and did something like COMMAND+P to open a file. In the middle of typing, this dialog stole focus, and the ENTER key chose ALLOW (or SPACE chose disallow) before I even noticed the dialog had appeared.

[jsejcksn]

I opened a workspace and did something like COMMAND+P to open a file. In the middle of typing, this dialog stole focus, and the ENTER key chose ALLOW before I even noticed the dialog had appeared.

Another problem with modal dialogs: stealing focus and accidental input (Enter, Escape, Spacebar, etc.)

[fortinmike]

I agree that this popup does nothing to enhance security. Most if not all people will just click "Allow" (it's well-known that users dismiss unsolicited popups as quickly as they can) and those who click disallow, probably by accident, will get a "broken" editing environment without linting, which can be problematic in a team as some pointed out. When you think about it, all dependencies must be trusted and imply some level of security risk, but I sure am glad I don't get a modal popup for each and every one of those.

I'd also vote for this to be removed ASAP until a better, less obnoxious and actually security-enhancing feature is implemented.

[y0nd0]

Yes this is annoying. Just use it. Priority: Try to use the local in node_module of the workspace and if not the globally installed one or nothing. And if you can't decide it for now, display a vscode notification. This notifications has the same features as the dialog. But I prefer a silent solution. Just use the workspace eslint or global one. Display an information about it if you want.

Please no options like "always allow" or something. No dialog at all. This should not annoy or confuse team mates. Everyone should use a linter. I don't understand why is this blocked by default? What is the reason for that dialog?

[rickbeerendonk]

I made a search/replace in 171 files and now I have two options:

• Click away 171 dialogs
• Kill VSCode in the task manager

[fanda2013]

very annoying popup very time

[dashersw]

Please remove this. If I deliberately install an ESLint in a project, I for sure want to use that version. Why should I ever use another version?

[fortinmike]

Since initially commenting on this, I accidentally dismissed the dialog a dozen times (I don't know what button I accidentally triggered) because I was typing when the dialog unexpectedly popped up (I think I had just quick-opened a file in a different project in my workspace, or opened one of those files in find results).

Did I disable eslint for part of my project, or did I keep it enabled when this occurred? I don't know. This must be removed ASAP, in my opinion.

[ryanblock]

@dbaeumer really feels like folks are trying to tell you this is not working for them. Will you continue to hold the position that you won't fix this glaring usability issue until eventually VS Code itself supports trusted workspaces? (Is that even something that could feasibly ship this year?)

For everyone else: you can opt out of this by:

• Opening extensions
• Click the gear next to ESLint
• Click Install another version
• I found 2.1.6 was the latest version that did not nag me for permissions

[bduffany]

Thanks @ryanblock for the suggestion to revert back to 2.1.6! Didn't know it was possible to install a previous version.

[dbaeumer]

I will not be able to revert this back due to the fact that this is a publicly know security vulnerability (see https://github.com/microsoft/vscode-eslint/issues/1012#issuecomment-658920804)

Having an Always Allow button can only come with a good UI indication that ESLint is trusted in general which goes along the lines of having a good UI for trusted workspace. So instead of me coming up with a custom solution I decided I better support VS Code as good as possible. To my knowledge the VS Code team already started working on this in August. I also committed to adopt this even if it is only proposed API and might need extra work on my side to improve the situation for ESLint users.

I started to look into using a notification instead of a dialog but I couldn't come up with a good flow so far. Major reason is that the VS Code API doesn't allow me to (a) cancel a notification or (b) make a hidden notification re-appear. Ideas / suggestions are welcome here.

[bduffany]

@dbaeumer I think a lot of people are going to revert back to 2.1.6 or possibly even uninstall vscode-eslint simply out of pure frustration (evidence: 4 people have put their thumbs-up on the comment made by @ryanblock only yesterday). For me personally, I reverted back to 2.1.6 because I kept switching between different packages inside a monorepo, where each package was using a different version of eslint, and I kept seeing the warning, which just got to be too annoying and actively thwarting my productivity.

IMO a temporary "Always Allow" button would be a good solution to avoid people uninstalling the extension (or worse, reverting to a previous version, which will result in people reporting bugs that have already been fixed, not realizing they are still pinned to the old version). Especially since none of us really knows how long it's going to take the VS Code team to implement the trusted workspaces feature.

Even though you committed to using their system, you aren't breaking that commitment just by adding a temporary "Always Allow" button, IMO.

[jsejcksn]

Major reason is that the VS Code API doesn't allow me to (a) cancel a notification or (b) make a hidden notification re-appear

The modal dialog is much more problematic than these listed concerns.

[dbaeumer]

The problem with the Always Allow is that I need to design something that is acceptable from a security perspective. It is not only about adding a button. Since VS Code needs to do the same I simply want to avoid the double effort.

The modal dialog is much more problematic than these listed concerns.

The concerns are not the API the concerns are the problems that raise with this. I will add the changes I already did to a branch. @jsejcksn may be you want to contribute if you have a good idea?

[jsejcksn]

may be you want to contribute if you have a good idea?

@dbaeumer I shared an idea earlier in this conversation about using a notification instead of a modal dialog, but you dismissed it.

Are you saying that you have changed your mind and now would like for someone to contribute a PR that replaces the modal dialog with a notification like the one I mentioned?

[dbaeumer]

@jsejcksn I did another attempt at it but it is still not nice. The easy thing about the dialog is that there is one question at a time and the user can't open another file when the dialog is present. This is completely different with notifications and the way how the API works. You might end up with n stacked notification asking for n different eslint libraries. In addition quite some management code needs to be written to ensure that you don't see two notifications for the same library. The solution is not to simply remove the modal flag. In addition I still think that there is a high change the users miss the notification. That is why in my current attempt the notification is behind a setting.

[bduffany]

@dbaeumer I think I understand where you're at now. You could implement your own "Always Allow" button, but the solution would essentially be identical to what the VS Code team is already trying to implement.

But I would hazard a guess that the VS Code is trying to implement something much more comprehensive, with UI controls for trusted workspaces, etc., and it's going to take them a while.

It seems to me like all you would need to do is keep a cache like { '$workspaceFolder': '$hasClickedAlwaysAllow' }, then check if (!hasClickedAlwaysAllow[$workspaceFolder]) showModalDialog().

Would it be more complex than that? I'm not an expert in VS Code by any means so I'm not sure if the concept of workspaceFolder is even applicable, or whether VS Code even lets you keep a cache like that.

This may have its own security issues (e.g. what happens if you replace a workspace folder with a different workspace?), but IMO this would be strictly more secure than people reverting to version 2.1.6 out of pure annoyance.

FWIW, I don't think notifications are the right approach, for the reasons you mentioned (stacked notifications, people ignoring them, etc.)

[DLehenbauer]

I avoided being prompted for each new folder in a mono repo by pointing the plugin at a specific ESLint instance:

    "eslint.nodePath": "packages/common/config/eslint-config/node_modules/",      // Avoid prompts when detecting ESLint installation

[dbaeumer]

@bduffany do I understand you correctly that what you are suggesting is for all eslint lbraries in one workspace folder. It is not about allowing eslint for all workspace folders including future once.

[ranyitz]

Thanks @ryanblock I'm going to revert to 2.1.6.

@dbaeumer In case someone successfully inserted a malicious version of eslint to my node_modules directory I would most probably won't know about it and press allow anyways. Therefore I don't see how this increases the security. It just resulting with more manual clicking and like most people said, you can easily ignore the popup and you'll get a problem which is not clear how to solve (eslint is now disabled for this project).

[ranyitz]

Adding a visual explanation for the workaround (Installing the version of this plugin that didn't include this change)

[rjgotten]

@ranyitz
In case someone successfully inserted a malicious version of eslint to my node_modules directory I would most probably won't know about it and press allow anyways.

Doesn't even have to be the case that it's the eslint module itself which is malicious. Could be any plugin loaded by the eslint configuration and in case of the configuration being a .eslintrc.js file -- i.e. it being full on executed JavaScript -- it could even be the configuration file itself.

[ramigs]

as suggested by @ryanblock reverting to 2.1.6 solved it for me

[martintasker]

I've just downgraded eslint to 2.1.6.

I'm really sad about this. VS Code is a fabulous IDE, the eslint plugin is brilliant tool. But this UX since mid-July is the first really silly thing that's happened since I've started using Code.

Just to add another dimension of pain, I have very poor eyesight, which means on the one hand that I particularly appreciate VS Code's beautiful design, and on the other hand that this dialog is doubly annoying because it's just plain old hard-to-read native stuff.

Please, @dbaeumer, can you persuade whoever needs persuading in the VS Code project, that all reasons for the post-July behaviour are irrelevant compared with the regression in usability.

[Laev]

as suggested by @ryanblock reverting to 2.1.6 solved it for me

This also helped me

[dbaeumer]

@martintasker the VS Code team started work to come up with a better UI that I can reuse. See my comments here https://github.com/microsoft/vscode-eslint/issues/1012#issuecomment-675523469 explaining that I am unable to simply revert that back.

[martintasker]

@martintasker the VS Code team started work to come up with a better UI that I can reuse.

Sounds good. Thanks @dbaeumer.

[dpistoleKUBRA]

This one bit me. I've lost 3 days of productivity trying to move eslint config around to figure out why I would get way more typescript lint errors from my npm lint script (which uses ./node_modules/.bin/eslint) compared to the code editor.

I assume at some point in the past I clicked something other than Allow on the prompt out of frustration at its frequency. I was getting _some_ errors (not nearly as many as from npm lint though, which uses a local eslint) so maybe it was falling back to some globally installed (and likely older version of) eslint or something.

The fact that it's not in the settings JSON made it _extra_ hard to find the solution. Ultimately the ESLint: Reset Library Decisions step outlined here fixed it for me.

Love VS code, hate that prompt and am glad you guys are working on a better solution. Thanks for your efforts.

[dbaeumer]

For others that hit this: there is a visual indication in the status line that ESLint is blocked.

[Gameghostify]

Had to revert to 2.1.6 as well

It would be awesome if there was a flag to opt-out

Being opt-in by default is a good thing as it's for security, but letting us opt out with a setting like eslint.disableLibraryDecisions is something that feels like it's missing at this point

[rjgotten]

letting us opt out

... would open a security hole. A malicious project could include that setting in a .vscode/settings.json file local to the project, override your choice and force their doctored ESLint to be used directly.

[bduffany]

letting us opt out

... would open a security hole. A malicious project could include that setting in a .vscode/settings.json file local to the project, override your choice and force their doctored ESLint to be used directly.

@rjgotten I don't see your point -- if you downloaded a malicious project, you are already screwed. Running yarn install / yarn start within that project could do god knows what to your computer. If someone got you to download their malicious project, why the heck would they use ESLint as the attack vector? They could just execute arbitrary code using the programming language of their choice.

[dbaeumer]

@bduffany the problem is that you can create a Git repository with all node_modules included. In this case the user simply needs to open VS Code on it and the ESLint extension executes the code without the user knowing.

In the yarn install case the user needs to type an install command in a terminal.

[bduffany]

@dbaeumer Does not every other extension run into this problem? What about Prettier, TypeScript, etc.?

[dbaeumer]

I can't talk about Prettier. TypeScript doesn't since by default they use the TS version that ships with VS Code. If you want to use a workspace version you get prompted and need to confirm that.

[rjgotten]

if you downloaded a malicious project, you are already screwed.

That's pretty much the point I've been making before as well. There are way too many attack vectors possible to cover them all.

Even when a project doesn't pre-include a malicious node_modules folder and the user has to actively perform npm install it's still possible to be screwed over with a malicious module. _Even_ if you vet the package.json file. Because most people will still forget to check the .npmrc dot-file and that can reconfigure the repository URL and point it to a compromised repository.

The point of contention then becomes; do you want to lessen that attack-surface by sacrificing usability?
Is the trade-off worth it, even if it would _still_ leave a hole a mile-wide.

And there's something to be said for both sides in that debate.

Realistically, the only way to make this 'safe' would be to only load the ESLint module from node_modules after you've computed a checksum hash over its contents and those contents match a known version. That means this VSCode extension would never be forward compatible and you'd always need an update to support newer ESLint releases. Well; unless you could get hold of those content hashes out-of-band. Maybe by querying the NPM servers?

(Wouldn't it have been nice if the whole node_modules and NPM architecture would've been put together with some actual architectural forethought for security and authentication, and have support for things like signed packages as first-class citizens?)

[trideepgogoi]

This might seem like a minor inconvenience, but for folks that work on multiple projects and a large code base this is turning out to be a nightmare.
Even If I accept the security issues around this, the dialog is completely unintuitive. I would guess that most folks are simply going to click the "Allow" Button anyways since there's no indication of why you would want to click Do not allow. And if you click on Do not allow, not having ESlint run create its own headache.
This isnt really solving the security issue (a real fix would mean disabling all 3rd party plugins). If the purpose is to inform the user that can be done via a warning. Asking the user a seemingly random question is 100% unintuitive.
This is compounded by the fact that most folks encountering this have now probably spent days trying to fix their own configs before finally stumbling onto this Issue.

[javierguzman]

I have a workspace with two folders inside. Each folder has its own "node_modules". Is there a way to tell ESLint to use the respective eslint within the respective node_modules depending what file I am viewing? So far, let's say I choose eslint uses folder1 node_modules, even if I do stuff in folder2, eslint will keep using folder1's node_modules which I think it does not make sense.

Thanks

[dbaeumer]

The extension uses the installed eslint version closest to the file you are validating using ESLint's lookup rules. Can you provide me with a GitHub repository that demos what you are seeing. It should work the way you described it.

[javierguzman]

I have tried to reproduce it but I have been unsuccessful. I have reset everything now and I have observed I get this output:

[Info  - 17:55:20] ESLint library loaded from: /blabla/application/client/node_modules/eslint/lib/api.js
[Info  - 17:55:26] ESLint library loaded from: /blabla/application/server/node_modules/eslint/lib/api.js

I guess once the eslint plugin has the library loaded it switches between them on the fly depending on whether you are editing a file from client folder or from server, right?

Thank you in advance.

[dbaeumer]

I talked to the VS Code team about trusted workspaces and unfortunately the feature will not be ready this milestone. So I invested quite some time to improve the situation in ESLint knowing that this is throw away work. Here is how the new model works:

• when ESLint starts on a file for which the executing of the ESLint library has not been approved yet you get a red status in the status bar. No more modal dialog. Lets hope that most people spot this:

• If you click on that status bar item the confirmation dialog opens. The dialog contains also an Always Allow button

• If you press the Always Allow the status bar item will contain a global symbol to indicate this. I am working with the VS Code team to get a double check icon which would better symbolize this.

• if you disabled or deny the execution you get the blocked sign

A test version of the new extension is here: https://github.com/microsoft/vscode-eslint/releases/tag/2.1.9-insider

I would like to ask people from the community to give it a try especially those who reverted back to 2.1.6. Please add comments to this issue with your feedback.

[infacto]

What is this dialog for? Why allow / disallow? Just use the eslint of the workspace or if not exist, use global. Other settings could be configured in the settings json of vscode. I do not understand the problem. Simply use the eslint of node_modules from my project. Every team mate should use the workspace one. No options / dialog.

[javierguzman]

@infacto I have a workspace with two folders "client" and "server" and each one has its own node_modules so I guess that dialog is for that. However, if in reality you can only select one eslint for workspace (I do not know about this), then you are right, it does not make sense to ask about this.

[dbaeumer]

You can individually allow or deny each eslint version in client and server.

[infacto]

@javierguzman Hmm... no I doubt it. Because eslint should just take the eslint from the related node_module folder. So, in your case it should work. If not, it's should be improved. But not with such a modal "feature".

Why should I "individually allow or deny each eslint version"? Just use the only one installed from node_modules of the related workspace / path. If a Workspace have multiple node_modules (package.json) so just take this. I'm really confused, because it makes no sense for me. 🙂 You have one eslint version in your package.json(s). And if I'm wrong, and there is a good reason for the current allow-behavior, just use settings. A config file or vscode settings. Instead of a blocking dialog. Or - as described here - "always allow", which can be stored in the settings.json in workspace of vscode. So that no team member is bothered.
I think the reason for that dialog only affects <1% of the users. Is there a related issue / request for that? I guess this is just a misunderstanding or bad implementation. It happens. But we should change it as soon as possible. ...

I'm working on a workspace for a mixed-skilled team. I try to make it as easy as possible for everyone to understand. I want to control that. No options for individuals. The most users click on "X" (close), "cancel" or "no" when such modal dialogs pop up. It's statistically proven.

I'm working on a workspace for a team with mixed skills. I try to make it as simple as possible for everyone to understand. I want to control that. No options for individuals. Most users click on "X" (close), "Cancel", or "No" when they see such modal dialogs.
Btw. how to reset this setting? For example if someone miss-clicked. Where is this choice stored?

[rjgotten]

@infacto
Why should I "individually allow or deny each eslint version"? Just use the only one installed from node_modules of the related workspace / path.

Because it's a possible attack vector. If the extension automatically executes node_modules code within VSCode, then it's possible for doctored projects to be put on e.g. GitHub to leverage this to infect unaware users with malware. All that takes is a specially prepared malware-laden ESLint tucked into a node_modules folder that comes as part of the project's Git repository.

There are plenty of other creative ways of third-party downloads accomplishing this, ofcourse. In the end it needs a proper sandboxed solution in VSCode and it looks like the VSCode team is working on something close to that end, atleast. But in the meantime, the author of the ESLint integration extension is choosing to put in this dialog as a mitigation on the extension's end.

[infacto]

That's not the only extension which executes node_modules. It's a general problem of all node scripts. Security is a good thought. DinoJS is one attempt to solve this. But ESLint requires file access etc. So such general sandboxed runtime will not work. At most only the Workspace should be sandboxed. But does this work? Some extension may requires more stuff from outside. Such permissions system (like on mobile devices) can be complicated. But yes, a proper sandbox is a good idea. And restricted extensions with limitations. With no options. Because ...

Also with dialog, I will click on "Allow" for sure. So it makes no difference. Malware or not. How can I detect it in this dialog?
Yes, it prevents accidental loading. ... 🤔 There are some question: Should the ESLint extension the only extension with this behavior? All other extensions are still risky. ... Are there reported issues with ESLint which triggered this behavior? ...
Is it possible to validate the correct version of ESLint by signing or checksum?

But ok, thanks for the informations. I hope for a better solution soon. ...

[rjgotten]

@infacto
You've just cited pretty much all the concerns I previously _also_ voiced with this type of dialog.
We're sort of on the same page here, it seems. 😉

[dbaeumer]

I will close the issue. I have delivered a new dialog experience which doesn't pop up a modal dialog anymore. Please open new issue when you think the new experience still needs polish