The VSCode settings.json file is getting created on non-HA repos

[pedrolamas]

When I open some random repositories on VSCode, I can see the .vscode/settings.json getting created, yet those repos have nothing to do with HA configuration!

A good example if the zigbee2mqtt: just clone the repo, open in VS Code (do ensure that this extension is enabled and running first) and observe the file getting created.

Extension runs in:

• VS Code for Desktop
• Hassio Add-on
• Visual Studio Online
• Other:

I'm running VS Code on:

• Windows
• Mac
• Linux

I'm accessing my files:

• From local disk
• Via remote SSH
• Smb
• Other:

[frenck]

.vscode/settings.json is a vscode settings file and not specific to this extension.
The extension doesn't even manage that file? What makes you conclude it comes from this extension?

[pedrolamas]

Sorry @frenck, but I believe this block tells me otherwise:

vscode-home-assistant/src/extension.ts

Lines 336 to 338 in 438700f

	await vscode.workspace
	.getConfiguration()
	.update("files.associations", { "*.yaml": "home-assistant" }, false);

This is what created the file and the content on it matches what is there!

[frenck]

Well spotted! Thanks for providing that insight 👍

[scrthq]

+1 to this, I have to uninstall/disable the extension as it injects workspace settings in workspaces that have nothing to do with Home Assistant. This feature is nice for new users but is a bit overkill. If someone wants to add the file association manually then it would be great to have as a how-to in the documentation of the extension, but I feel like someone that's familiar enough to get to the point of installing the VSCode extension for Home Assistant intellisense/snippets/etc is going to be aware of fileAssociations in Code

[DavidDeSloovere]

Several times a week this gets added. Always have to revert (git) the change.

"files.associations": {
    "*.yaml": "home-assistant"
  }

Would it be possible to check for known HA files to conclude it's an HA folder, and only then add the file associations?

Look like there is something built-in already

vscode-home-assistant/package.json

Lines 27 to 33 in 438700f

	"activationEvents": [
	"workspaceContains:**/configuration.yaml",
	"workspaceContains:**/ui-lovelace.yaml",
	"onFileSystem:ftp",
	"onFileSystem:ssh",
	"onFileSystem:sftp"
	],

So the extension gets activated incorrectly.
Check only for home-assistant_v2.db would be stricter, and I'm guessing you can't have HA without home-assistant_v2.db.

Or maybe have a setting to the extension to disable this?

Somewhat related #137

[scrthq]

I'd love this to be a configurable setting for the extension, since it does add value for some users, I'm sure. This would also not break the default behavior of the extension but allow for a little more granularity around when that feature is desirable.

Checking out the code and sending a PR if it's manageable

[scrthq]

PR #1026 created to add the setting to disable automatic file association.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[pedrolamas]

Still an active issue...

[DavidDeSloovere]

Yup, I also still see this weekly.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[pedrolamas]

Still an active issue...

[pedrolamas]

This is getting old quite fast...

Here's another example of a completely unrelated HA repo getting the offending settings.json file created... 😕

[silverl]

Same here. Keeps happening in a variety of repos I work on that contain .yaml files.

[Unfocused]

The YAML format is used by a LOT of different tools and projects. So in almost every project I have, this extension forcibly inserts its own settings into the project's .vscode/settings.json or .code-workspace file (which are committed to version control) to forcibly associate itself with all YAML files in that project. And if that change is removed, the extension automatically re-adds it.

That's what I would call viral behaviour.

It is not ok to do this. Further, I would expect that such behaviour wouldn't be accepted by the VS Code Marketplace.

[pedrolamas]

Fact is this plugin is exhibiting a dark pattern, no other way to put it.

The fix is trivial and easy for any maintainer - just stopping auto adding the plugin as handler! - but considering the amount of time that has passed since I opened this ticket and nothing actually changed, I don't think any action will be taken to change this.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[pedrolamas]

Still a valid issue.

[MaxVRAM]

This is such a pervasive issue that I've sadly had to drop the plugin. 18 months later, I'm assuming it's not getting fixed.

[frenck]

Fixed by #3572