salesforcedx-vscode: Don't modify eslint path automatically, don't automatically change user settings

Every time I open VSCode this extension automatically adds "eslint.nodePath": "/Users/myuser/.vscode/extensions/salesforce.salesforcedx-vscode-lwc-45.15.1/node_modules" to my settings.json file.

Please stop auto modifying config files, this affects any VSCode session I open regardless of it’s a Salesforce project. It happens without prompting. Your extensions have already fully deleted my local config settings in the past from trying to do things like this. Now you’re auto modifying them? Please don’t add behavior like this to plugins!

This breaks any project with custom ESLint plugins, because it tries to use a randomly installed one in the sfdx plugin, not the correct locally installed on per project.

For anyone else who has their config mangled by these bad actor plugins and starts seeing errors like this because it’s using a randomly installed eslint:

[Error - 11:43:40 AM] Cannot find module 'eslint-plugin-prettier' Referenced from: /Users/me/repo/.eslintrc.js

You can block the bad plugin by setting it manually:

  "eslint.nodePath": "./node_modules"

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 8
  • Comments: 15 (4 by maintainers)

Most upvoted comments

yikes

this is a serious issue, please re-open

I am not a happy camper at the moment because the build and deploy is failing due to conflicts caused by jsconfig.json being randomly rewritten. To follow up on my previous post:

  1. Who/what exactly is rewriting jsconfig.json?
  2. Why are they doing so?
  3. Why does jsconfig.json seem to require a paths property which points each LWC in the tree to itself, more or less?
  4. How can we turn off rewriting jsconfig.json?
  5. If we are able to turn off the rewriting and do so, what is the impact? Will we need to manually update it each time we add a new LWC to the tree?
  6. What is the purpose of jsconfig.json? Who is consuming it?

If for some reason there is a need to rewrite jsconfig.json, then a better approach would be to provide a script or SFDX command that creates a new one that people could use when, and only when, they want to.

Appreciate your help.

I am too confused by this topic. So I want to write down my solution. If something wrong, please someone tell me the problem.

For preventing modify .vscode/settings.json, most straight forward solution is to set own nodePath within .vscode/settings.json. Like @AndrewRayCode said.

  "eslint.nodePath": "./node_modules"

And we may also have force-app/main/default/lwc/.eslintrc.json and it contains like below configuration, so I need to run npm i -D @salesforce/eslint-config-lwc.

{
  "extends": ["@salesforce/eslint-config-lwc/recommended"]
}

At this moment, this seems working in my eyes.

The ticket which was closed as a duplicate of this one actually raised a semi-separate issue, which is that someone is magically recreating and/or rewriting jsconfig.json. Why would you do that? Why would it be rewritten, as it is in my case, to include every single component in the paths object? This can cause odd merge conflicts. Or should jsconfig.json be considered an artifact not kept under version control? Or is this some VSCode extension thing, and if so triggered by what? Or am I missing something and our ages-old build system with random patches for LWCs doing something that I can’t see which results in re-creating jsconfig.json?

I am having the same issue with overwriting the configuration; force-app\main\default\lwc\.eslintrc.json.

I want to provide custom ESLint rules along with the Salesforce provided rules. I am not able to modify force-app\main\default\lwc\.eslintrc.json, because it gets rewritten when VSCode is reloaded.

I am able to include my additional rules by providing configuration with the command in the script in the package.json, but I should be able to update the .eslintrc.json file if I want without it be rewritten.

"scripts": {
  "lint:lwc": "eslint --plugin my-plugin --rule \"my-plugin/my-rule: 2\" **/lwc/**"
}

Our developers are facing this same problem. Please address.