Add setting to disable automatic YAML file association

[scrthq]

Should resolve #961 without changing existing default behavior.

Changes:

• Add boolean setting vscode-home-assistant.disableAutomaticFileAssociation (defaults to false).
• Update HomeAssistantConfiguration interface and ConfigurationService class with the disableAutomaticFileAssociation property (not currently used, but keeping LS configuration in sync with available configuration options).
• Update to fileAssociations section of extension.ts with an additional conditional check in the if statement to read in the new configuration setting.

[frenck]

While this is a nice option, we should improve the detection on when to enable it... This feels more like a workaround for the problem.

[scrthq]

@frenck - Agreed that this is a workaround and better detection would be great, but I still feel like there should be an option to disable it entirely (ideally default to that behavior being disabled and allow opt-in instead of opt-out). I can't think of any other extension that modifies workspace settings like this, especially creating files when they might not already exist purely for the sake of convenience. Shouldn't need to keep the extension globally disabled and enable per workspace simply to avoid unexpected behavior.

Detection is nice and all, but configuration.yaml isn't exactly a naming convention that's specific to Home Assistant and there aren't really other required files to maintain in a Home Assistant focused workspace, especially when using add-ons like the Git Pull add-on where you don't have every Home Assistant file in your Home Assistant Code workspace.

If there's something that you're thinking of that would be a step in a better direction, I'd be happy to modify my PR with the recommended changes.

[frenck]

Detection is nice and all, but configuration.yaml isn't exactly a naming convention that's specific to Home Assistant and there aren't really other required files to maintain in a Home Assistant focused workspace, especially when using add-ons like the Git Pull add-on where you don't have every Home Assistant file in your Home Assistant Code workspace.

I don't agree with that, as it is pretty unique to be configuration.yaml that contains a homeassistant key.

[scrthq]

That's fair if we're parsing the YAML file to check the contents as well! Right now excluding my additions, the fileAssociations section appears to only check if the workspace settings file does not contain a key of *.yaml and does not contain a value of home-assistant before it updates/creates the workspace settings file. I'm not seeing anything that actually looks at content or even looks for a configuration.yaml file in the workspace.

There are bits on haConfig.ts and haYamlFile.ts that do some parsing, but those aren't referenced in the extension.ts segment that manages the actual settings fileAssociations.

[scrthq]

From what I can tell, it looks like the extension is activated for file presence of configuration.yaml or ui-lovelace.yaml and the extension client activation checks the settings file and updates it based on the contents of the settings, not the contents of the configuration.yaml file.

[frenck]

That is correct, I was referring to the fact that it should be improved, not worked around.

[scrthq]

Checking that out! I'm not a TS/JS developer typically, so this should be fun 😄

[scrthq]

@frenck -- curious if you have some rough implementation guidance here. Seeing your parseAstRecursive function in language-server/src/haConfig/haYamlFile.ts which appears to be useful here (at least a subset of it). I'd like to avoid repeating code between the extension.ts and the language server code, but I'm not sure offhand if that's doable based on how the current file/function structure does not appear to show any shared code between the two. I think some sort of common module might be good here, but we obviously don't need the full AST just to check if configuration.yaml/homeassistant path exists. Fallback option would be to define a single purpose function/check directly on extension.ts, but trying to avoid that becoming too bulky if possible.

[frenck]

I honestly think this is more up into @keesschollaart81 his alley

[Nicholaiii]

You can disable/enable extensions per workspace, so there's really no need for a boolean setting, however nice it may be. You can globally disable vsc-ha and enable it only in your HA workspace