An option to place config in a dedicated file (not in the .vscode/setting.json)

Good day!

Thanks for taking care of this super useful module!

We use it as the default way to build css from scss in our projects. So the module config is actually a part of the project and should be version controlled. But the config is stored in .vscode/setting.json, which contains env specific stuff like, for example, peacock settings and lots of others, that should be set differently for different users.

Could we store vscode-live-sass-compiler’s settings separately (as an option)? In a special config file or in some generic sass setting file (if it exists)?

[glenn2223]

No, I understood what you wanted. However, as I said, I had my reservations;

• if someone was to import a project with this new file. In the VSCode settings GUI, and in the settings.json file itself, it would have one thing, but the result would differ without any obvious reason as to why
• someone at a workplace has one folder with a bunch of different projects linked to it so their paths would differ from someone else’s (who just has that one folder/project) and they have no control over adjusting the settings

It’s also worth noting that microsoft/vscode#15909 will also work in this way (settings from work overridden by user’s personal settings.json)

The files you’re referring to are the start and end of the hierarchy, but the settings in VSCode are hierarchical.

Sorry don’t mean to be argumentative in any way, just want to make my points. This is all very much in the air so I’m open to being convinced that there is a better way

[glenn2223]

Sorry, I thought I’d replied to this.

I don’t think you can trigger an extension method with a task. I think they’re more for things like building (may be wrong though)

I had a thought. As you want to have separate user and project settings, why not strip user settings from the .vscode/settings.json file and then use VSCode’s user settings for personalisation settings?

---

FYI: still planning on implementing it in the future. However, more in line with being global (not overwritable)