vscode-home-assistant
vscode-home-assistant copied to clipboard
The VSCode settings.json file is getting created on non-HA repos
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:
- [X] VS Code for Desktop
- [ ] Hassio Add-on
- [ ] Visual Studio Online
- [ ] Other:
I'm running VS Code on:
- [X] Windows
- [ ] Mac
- [ ] Linux
I'm accessing my files:
- [X] From local disk
- [X] Via remote SSH
- [X] Smb
- [ ] Other:
.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?
Sorry @frenck, but I believe this block tells me otherwise: https://github.com/keesschollaart81/vscode-home-assistant/blob/438700f8b16585f58154194b0c3a1555fa51a916/src/extension.ts#L336-L338
This is what created the file and the content on it matches what is there!
Well spotted! Thanks for providing that insight 👍
+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
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 https://github.com/keesschollaart81/vscode-home-assistant/blob/438700f8b16585f58154194b0c3a1555fa51a916/package.json#L27-L33 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 withouthome-assistant_v2.db
.
Or maybe have a setting to the extension to disable this?
Somewhat related #137
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
PR #1026 created to add the setting to disable automatic file association.
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.
Still an active issue...
Yup, I also still see this weekly.
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.
Still an active issue...
This is getting old quite fast...
Here's another example of a completely unrelated HA repo getting the offending settings.json
file created... 😕
Same here. Keeps happening in a variety of repos I work on that contain .yaml files.
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.
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.
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.
Still a valid issue.
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.