Code Monkey home page Code Monkey logo

vscode-workspace-config-plus's Introduction

Workspace Config+

Provides additional capabilities to manage your "workspace" configuration settings, including the ability to utilize shared and local versions of the VS Code workspace configuration files.

Note: A VS Code "workspace" is usually just your project root folder. This extension can be immediately used in standard, single root/projects, as well as more advanced, multi-root workspaces. See the VS Code docs What is a VS Code "Workspace"? and Workspace Settings for more information.


Functional, but still in Beta !!!!


Version Badge Installs Badge Rating Badge License Badge

Linux CI Badge Mac CI Badge Windows CI Badge

Test Results Badge Coverage Badge Sonar Quality GateBadge

Current Features

  • Adds support for shared and local configuration files (.vscode/*.shared.json, and .vscode/*.local.json)

Shared and Local Configuration Files

With this extension you can now split your project's workspace configuration between shared files that can be checked into version control and shared with other team members, as well as local configuration overrides/extension that are excluded from version control.

It currently supports:

  • settings.json - (settings.shared.json, settings.local.json)
  • tasks.json - (tasks.shared.json, tasks.local.json)
  • launch.json - (launch.shared.json, launch.local.json)

Setup

Be sure your *.local.json files and the main VS Code files are excluded from version control by adding the corresponding entries to your project's ignore file (e.g. .gitignore, .hgignore). For example:

# .gitignore
.vscode/*
!.vscode/*.shared.json

Then just add your desired *.shared.json and/or *.local.json files to your .vscode directory in your workspace folder(s). The extension works with both standard (single root) workspace projects and multi root workspaces.

Enter the values that you want to share with other contributors into the *.shared.json file, and any personal/local overrides and additional settings to the corresponding *.local.json file. The configuration values defined in a *.local.json file will take precedence over any conflicting values defined in the corresponding *.shared.json file.

The extension will re-evaluate and, if necessary, automatically apply any configuration updates any time any supported *.shared.json or *.local.json files are added, modified, or removed, as well as when additional folders are added to a workspace. As such you never have to worry about running any commands!

This extension is not an all-or-nothing proposition. Team members and contributors that want to take advantage of the shared configuration defined in the *.shared.json files only need to have this extension installed and enabled. Any contributor that doesn't want to pull in any of the project's shared configuration can either not install or disable this extension, or they can create a corresponding *.local.json file to override the shared settings.

Settings

Note that currently Workspace Config+ requires you to specify any of the below settings in your "workspace" files, and it doesn't yet support setting them at the user/machine global level.

If you'd like to use these settings to modify the behavior of Workspace Config+ ,then you'll need to add the setting to either settings.local.json or settings.shared.json

arrayMerge

Allows you to specify how the extension should handle array-type keys that are defined in multiple places (i.e. in both the *.shared.json and *.local.json))

Default: combine
Supported values: [ combine, overwrite ]

When set to combine, the two array values will be combined in the final result.

For example, if you have the following:

tasks.local.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "My awesome personal task",
      ...
    }
  ]
}

and tasks.shared.json

{
  "version": "0.1.0",
  "foo": "bar",
  "configurations": [
    {
      "name": "Shared Team task #1",
      ...
    }
  ]
}

The end result in tasks.json that VS Code will see and honor will have both of the tasks defined under the configurations arrays in the shared and local files:

tasks.json

{
  "version": "0.2.0",
  "foo": "bar",
  "configurations": [
    {
      "name": "My awesome personal task",
      ...
    },
    {
      "name": "Shared Team task #1",
      ...
    }
  ]
}

However, if you change the value of the setting to overwrite, then the overlapping configurations array value in *.local.json will be used instead, producing the below for tasks.json:

{
  "version": "0.2.0",
  "foo": "bar",
  "configurations": [
    {
      "name": "Shared Team task #1",
      ...
    }
  ]
}

Limitations

All configuration setting values are ultimately stored and persisted in the native VS Code workspace configuration files (e.g. .vscode/settings.json). However, because these features are added via an extension there are some associated limitations and accordingly we'd strongly advise against manually modifying those native files when using the extension, and instead advise managing your configuration in the shared/local files.

  • You can utilize inline comments in the *.local.json and *.shared.json files, but any comments from those files are not persisted into the native VS Code configuration file.
  • Any comments added to the native VS Code configuration file (e.g. settings.json) will be lost when any configuration updates are applied based on changes to the local/shared files.
    • Some other extensions may automatically add configuration values to the native files with comments, so we'd advise moving any such configuration values to the corresponding *.local.json or *.shared.json file if you'd like to maintain the comments.
  • The extension does not monitor any changes made to the native VS Code configuration files (e.g. settings.json), so if you manually modify a value in one of those files then that takes precedence with VS Code.
    • If you mistakenly modify the native file, the easiest way to trigger this extension to correct the configuration is to modify the corresponding shared or local file (e.g. add a blank line and then save).
  • This extension only works with the workspace configuration files, and doesn't allow for configuration values to be edited in the VS Code Settings Editor interface.
  • We've tested and validated the extension with both single and multi-root workspace projects. We have not had a chance to test with VS Code Remote SSH based workspaces, nor browser-based workspaces like GitHub Codespaces. We don't necessarily expect any particular issues in those types of projects, but just haven't been able to test and validate (if you do, and want to test, please let us know!)
  • Our understanding is that you will not be able to sync your *.local.json files if you are a user of the native VS Code Settings Sync feature. However, the Settings Sync Extension may support synchronizing the *.local.json configuration files too.

Background

VS Code is highly configurable, and allows you to configure specific workspaces in addition to your global user settings.. This includes things like general settings, such as the zoom level, as well as [tasks and launch configurations] amongst others. These configurations are stored in various respective files within the .vscode directory in the workspace. For example, the workspace task configuration is stored in .vscode/tasks.json.

This works fantastically, but unfortunately often poses a challenging question for teams or projects that have more than one author since they have to determine whether or not to track the configuration file(s) in version control. If they include the files in version control then they'll often run into conflicting opinions or even conflicting settings, such as those from extensions which are specific to the developer's local file system. However, if they exclude the files from version control then they give up the ability to share elements that are helpful for other developers and force contributors to manually duplicate part of their setup.

There are some longstanding requests from the VS Code community (microsoft/vscode#40233, microsoft/vscode#37519, microsoft/vscode#15909) to extend the product to address these concerns, and we hope to see a resolution natively within VS Code some day. This extension should help fill the gap in the interim however.

Feedback

Found a bug, have an idea for a new feature, or a question? Please reach out to us on the project GitHub repository by opening an Issue or starting a Discussion!

Like this extension? Please consider starring the repo on GitHub!

You can also share feedback by rating the extension and/or leaving a review on the Marketplace.

Contributing

All contributions are welcomed and appreciated! See the Contributing guide for more information.

License

MIT - see license details here

Code of Conduct

This project follows the standard Code of Conduct as other Swellaby projects, which is the Contributor Covenant

vscode-workspace-config-plus's People

Contributors

calebcartwright avatar dependabot[bot] avatar swellbot avatar witcher112 avatar florianhumblot avatar gamrix avatar

Stargazers

Kim, Jang-hwan avatar Pelle Wessman avatar Kevin James O'Dea avatar  avatar Sam Lin avatar Sam Lin avatar Biniam Bekele avatar Ivan Gretsky avatar bb010g avatar Chris Motch avatar Bill Ticehurst avatar Scott Walters avatar  avatar  avatar Christophe Dervieux avatar  avatar vancaem avatar Matthew Strasiotto avatar Kyle Summers avatar Kody Brown avatar Pedro Fialho avatar Liming Du avatar  avatar Nils Henrik Hals avatar Yeechan Lu avatar

Watchers

James Cloos avatar  avatar  avatar  avatar

vscode-workspace-config-plus's Issues

Merging `launch.*.json` to `launch.json` only merges `launch.local.json`

Same issue as #111 but for launch.json merging.

Files

launch.shared.json

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "java",
            "name": "Attach to Remote Program",
            "request": "attach",
            "hostName": "localhost",
            "port": "5005"
        }
    ]
}

launch.local.json

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "java",
            "name": "Attach to Remote Program",
            "request": "attach",
            "hostName": "localhost",
            "port": "5006"
        }
    ]
}

launch.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "java",
      "name": "Attach to Remote Program",
      "request": "attach",
      "hostName": "localhost",
      "port": "5006"
    }
  ]
}

Please do not hardcode the file names...

Right now the file names that are required for this to work:

{settings,tasks,...}.shared.json
{settings,tasks,...}.local.json

Can you pretty please allow wildcards?
Our use case is that we would like to have more than 1 file for settings, ie:

python.settings.shared.json
js.settings.shared.json
java.settings.shared.json
...
style.settings.shared.json

But then why even use shared or local suffixes? It would be way more beneficial to not lock into the names and instead maybe watch for changes in any files that have .settings.json or .tasks.json, etc suffixes and then deep merge them as you do right now with local and shared?

Merging `tasks.*.json` to `tasks.json` only merges `tasks.local.json`

As the title of this issue for some reason the merging of tasks only merges the local.json file and not both.

Versions

Plugin

Name: Workspace Config+
Id: Swellaby.workspace-config-plus
Description: VS Code extension for improved workspace configuration
Version: 0.2.4
Publisher: Swellaby
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=swellaby.workspace-config-plus

VSCode

Version: 1.75.1 (user setup)
Commit: 441438abd1ac652551dbe4d408dfcec8a499b8bf
Date: 2023-02-08T21:32:34.589Z
Electron: 19.1.9
Chromium: 102.0.5005.194
Node.js: 16.14.2
V8: 10.2.154.23-electron.0
OS: Windows_NT x64 10.0.19044
Sandboxed: No

Files

tasks.shared.json

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "server-sonar",
            "type": "shell",
            "command": "${workspaceFolder}/deployment/podman/run_sonarqube.sh",
            "problemMatcher": []
        },
        {
            "label": "scan-sonar",
            "type": "shell",
            "command": "${workspaceFolder}/deployment/podman/run_scan_sonar.sh",
            "problemMatcher": []
        },
        {
            "label": "test-pipeline",
            "type": "shell",
            "command": "${workspaceFolder}/deployment/podman/run_all_test_pipeline.sh",
            "problemMatcher": []
        },
        {
            "label": "test-all",
            "type": "shell",
            "command": "${workspaceFolder}/deployment/podman/run_all_test.sh",
            "problemMatcher": []
        },
        {
            "label": "test-maven",
            "type": "shell",
            "command": "mvn clean test",
            "problemMatcher": []
        },
        {
            "label": "lint-java",
            "type": "shell",
            "command": "npx prettier --check \"src/**/*.java\"",
            "problemMatcher": []
        }
    ]
}

tasks.local.json

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "merge-develop",
            "type": "shell",
            "command": "git merge origin/develop",
            "problemMatcher": []
        },
        {
            "label": "lint-all",
            "type": "shell",
            "command": "npx prettier --check .",
            "problemMatcher": []
        }
    ]
}

tasks.json

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "merge-develop",
      "type": "shell",
      "command": "git merge origin/develop",
      "problemMatcher": []
    },
    {
      "label": "lint-all",
      "type": "shell",
      "command": "npx prettier --check .",
      "problemMatcher": []
    }
  ]
}

Tests

I update tasks.local.json with in the array of tasks

    {
      "label": "pull",
      "type": "shell",
      "command": "git pull",
      "problemMatcher": []
    }

which produceses on save [2023-03-01 09:10:40] [INFO] Updating config in /home/eriase/repos/quarkus-maven-project/.vscode/tasks.json.

After this I remove the added line from tasks.local.json the same log is produced and add it to update the tasks.shared.json and no log is produced at all โ˜น

If I add an incomplete json object like below the it failes to parse the tasks.shared.json file as excepted.

       {
            "label":
        }
[2023-03-01 09:18:54] [ERROR] Failed to parse contents of: /home/eriase/repos/quarkus-maven-project/.vscode/tasks.shared.json
[2023-03-01 09:18:54] [DEBUG] Error: Failed to parse contents of: /home/eriase/repos/quarkus-maven-project/.vscode/tasks.shared.json

Include extensions.json?

It's super easy to add support for new files so there's no question/concern relative to effort, but more of whether there'd be any utility to this given how VS Code interacts with the extensions.json file.

I'm 50/50 on it personally but opening it for discussion. If anyone would like to have the ability to use extensions.{local,shared}.json files then please use the reactions feature to indicate so.

Doesn't seem to work in dev containers

First, this is awesome!

Sadly it appears to not work when running inside a dev container. (Basically a docker instance.)

This might be too much of an edge case, but if you have any advice ideas on how I could diagnose this more that would be awesome!

Behavior:

  • I make changes to tasks.shared.json, and tasks.json is not updated

Running Windows, with my linux dev container (a Docker Container) run via WSL2.

Theoretically it should be possible for it to work I think. The editorconfig extension works within the devcontainer (it detects file changes on save and rewrites the file with correct styling).

Deleted config items in local or shared jsons are not removed from generated files

Example:
settings.shared.json

{
    "editor.detectIndentation": false
}

generates settings.json

{
    "editor.detectIndentation": false
}

Now if afterwards I'd comment out it in settings.shared.json:

{
    //"editor.detectIndentation": false
}

I'm left with the same settings.json:

{
    "editor.detectIndentation": false
}

Expected output would be for settings.json:

{
}

Fix support for multi-root workspaces

Some settings don't get applied in $PROJECT_DIR/.vscode/settings.json when you're working in a multi-root workspace. It would be nice to have settings copied into the workspace file when editing settings.{shared|local}.json, if possible ๐Ÿ™‚

This does present an additional challenge with nested projects (for example when using Git submodules). If a sub-directory has it's own settings, those should ideally be merged into the workspace file's settings as well.

"Failed to parse contents of" with "cSpell.words" settings.

Output

[2022-11-02 10:22:16] [ERROR] Failed to parse contents of: /Users/.../.vscode/settings.shared.json
[2022-11-02 10:22:16] [DEBUG] Error: Failed to parse contents of: /Users/.../.vscode/settings.shared.json

Contents

{
  "cSpell.words": [
    "foo",
    "bar",
    "biz"
  ],
}

Override a tasks with `tasks.local.json`

Hi!

I've started to use the extension and I found something that could we useful when merging tasks. Sometimes we just want to override a tasks and we want to keep other ones from the tasks.shared.json

Example

tasks.shared.json

{
  "version": "2.0.0",
  "tasks": [
    {
        "label": "A",
        "type": "shell",
        "command": "script A",
        "problemMatcher": [],
        "runOptions": {
              "runOn": "folderOpen",
          },
    },
    {
        "label": "B",
        "type": "shell",
        "command": "script B",
        "problemMatcher": [],
    },
  ]
}

tasks.local.json

{
  "version": "2.0.0",
  "tasks": [
    {
        "label": "A",
        "type": "shell",
        "command": "script A",
        "problemMatcher": [],
    },
  ]
}

Actual tasks.json with "arrayMerge": "overwrite"

{
  "version": "2.0.0",
  "tasks": [
    {
        "label": "A",
        "type": "shell",
        "command": "script A",
        "problemMatcher": [],
    },
  ]
}

Actual Actual tasks.json with "arrayMerge": "combine"

{
  "version": "2.0.0",
  "tasks": [
    {
        "label": "A",
        "type": "shell",
        "command": "script A",
        "problemMatcher": [],
        "runOptions": {
              "runOn": "folderOpen",
          },
    },
    {
        "label": "B",
        "type": "shell",
        "command": "script B",
        "problemMatcher": [],
    },
    {
        "label": "A",
        "type": "shell",
        "command": "script A",
        "problemMatcher": [],
    },
  ]
}

tasks.json with this functionality

{
  "version": "2.0.0",
  "tasks": [
    {
        "label": "A",
        "type": "shell",
        "command": "script A",
        "problemMatcher": [],
    },
    {
        "label": "B",
        "type": "shell",
        "command": "script B",
        "problemMatcher": [],
    }
  ]
}

Allow to configure deep merge functionality

As per discussed in #107, it would be good if we provide config options to control the deep merge behavior.

@calebcartwright to start a discussion here, what do you think about using https://github.com/TehShrike/deepmerge#ismergeableobject in order to add a property filter?

This way users would be able to specify which properties should be deep merged and which should not.

Second thing, I believe we should either

  • support the config property only in settings.shared.json as if it would be defined elsewhere, the merging process would be highly indeterministic
  • or put it in separate file (maybe vscode-workspace-config-plus.settings.json ?)

Also, an idea, but even I find it myself very non-standard and extreme - allow to configure it through JavaScript file vscode-workspace-config-plus-deepmerge-options.js that we can expect to export options object directly passed to deepmerge. On the other side, it would solve all of the issues and not force us to create an abstraction layer over deepmerge options.

Should we support OS specific configurations?

It would be fairly straightforward to expand our current supported features to also give folks the option to define platform-specific configuration files, e.g. settings.shared.json and settings.shared.{linux,darwin,windows}.json, to allow for platform specific overrides/shared configurations.

I don't have any concrete use cases in mind, but I do envision there's scenarios that could benefit from this especially when it comes to configurations like launch/debug settings.

Essentially, this would extend the configuration resolution priority order to something like the below list (settings.json used as an example, but would apply to all supported files):

  1. settings.local.{linux,darwin,window}.json
  2. settings.local.json
  3. settings.shared.{linux,darwin,windows}.json
  4. settings.shared.json

Track changes from `settings.json`

I wonder if we can introduce tracking of direct changes from settings.json and give the user an option to apply them to one of extension supported configuration files. It could serve as an improvement of the current behavior of merging with settings.json (we can for example block updating settings.json if we detect that it's out of sync).

I'm thinking of the scenario:

  • settings.json is produced as a result of merging settings.shared.json with settings.local.json and marked as synced
  • settings.json is modified (thus becoming non-synced)
  • extension detects it and sends the notification
  • user is presented with the option to "Sync" (either triggered manually or required before merging settings.shared.json and settings.local.json)
  • user can select the target configuration file where the diff would be applied (we'd need to perform some checks*)

Please let me know if that makes sense, I can take a look and start researching the possibilities (I guess some diff libraries would be the first thing to look for).

*we'd need to check that after applying the diff to one of our configuration files, produced settings.json would be the same as it was, otherwise we should block applying to certain config files (for example if the user would like to apply to settings.shared.json but in the same time his settings.local.json overrides the field - in such scenario only applying to settings.local.json should be possible).

Indentation style in modified native files

At the moment the way we're applying the configuration settings results in the native files (e.g. .vscode/settings.json) having 2 space indents. Obviously the tabs vs. spaces debate will continue through the end of the universe and there's going to be some folks that'd prefer tabs or different sized space indents.

I suspect the easiest way to address this is to add configuration options and just let users specify whatever they want, though I suppose it'd technically be possible to attempt to detect by inspecting the file and/or the corresponding shared+local pair.

Update extension metadata

We forgot to set the displayName attribute so the textual descriptions on the marketplace look more machine-friendly than human-friendly, and we could probably use some additional search terms as well.

Triggering the merge process manually

If we would like to consider #109 I think it would require an option to trigger the merge process manually. It could be done simply by exposing it through contribution commands.

I propose the name Merge workspace configuration.

As before, I can take a look at it :)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.