colorTabs config in GIT, but without workbench.colorCustomizations

[peter-lyons-kehl]

Having .vscode/settings.json in GIT is controversial. But I believe it's valuable (saving other collaborators' time). However, ColorTabs adds & modifies workbench.colorCustomizations, and that confuses versioning of .vscode/settings.json.

I guess we don't want ColorTabs to modify ~/.config/Code/User/settings.json instead, because that would affect other windows (if we have several workspaces open in their own windows). Was that the problem with race conditions mentioned in #7?

How about working around with multi-root workspace (even if we didn't need it to be multi-root):

1. having a multi-root workspace
2. reading colorTabs.config from multi-root config file .code-workspace (versioned in GIT), but
3. writing workbench.colorCustomizations not to multi-root config .code-workspace, but to the actual child workspace's .vscode/settings.json (which would NOT be versioned in GIT, potentially added to .gitignore). Unsure if that is possible in multi-root - https://code.visualstudio.com/docs/editor/multi-root-workspaces#_settings says that in multi-root workspaces UI state can't be saved in (child) .vscode/settings.json.

However, it seems that 2. above is not being applied - ColorTabs doesn't read/get settings from .code-workspace, even though its schema allows it. Example (for a clone of https://github.com/coop-rs/allows):

{
    "folders": [
        {
            "path": "allows"
        },
        {
            "path": "allows_internals"
        },
        {
            "path": "allows_tests",
        }
      ],
    "settings": {
        "colorTabs.config": [
            {
                "regex": ".*/lib.rs"
            },
            {
                "regex": ".*/Cargo.toml"
            },
            {
                "regex": "allows_tests/.*"
            }
        ]
    }
}

(unsure about the last regex - to be tested whether it would work compared to the top root (multi-root), or compared to the child root?)

Or, the other way:

1. having a multi-root workspace
2. reading colorTabs.config from each child workspace's .vscode/setting.json (versioned in GIT), but
3. writing workbench.colorCustomizations to multi-root config file .code-workspace (which would NOT be versioned in GIT, potentially added to .gitignore).

And/or, could there be any other way?

[KyleKolander]

This bit me, too. I only have one workbench color customization defined in my user settings.json. Whenever I open a folder in vscode, this extension automatically creates a .vscode folder with a settings.json file. The only thing in the file is that single workbench color customization that I have defined in my user settings.json. This extension should not do that. It needs to be smart enough to not duplicate color customizations that are in the user settings.json. I had to uninstall.

[marcellkiss]

We have the same issue, would be nice to be able to prevent it from modifying the .vscode/settings.json file all the time - if possible.

[oreporan]

the settings.json is what colors the vscode. Its impossible not to change it.

[marcellkiss]

Oh, that's a pity, as it's using merge-conflicts all the time.
Out of the scope of this project, but as a workaround for others with the same issue, a pre-commit hook script and could remove the changes.