Skip to content

Editing settings via CLI interface #169448

@2rs2ts

Description

@2rs2ts

I would like to attempt to revive interest in this past feature request: #99361

The original text of it is as follows:

Overview

code CLI is amazingly helpful for users that wish to quickly set Visual Studio Code up or even automate the setup altogether. For example, current CLI interface provides a great way to manage extensions from command line.

CLI interface would be even more useful if it also provided a way to read and update settings.

Proposed Interface

For example:

  • code --get-setting <name> could return a JSON value for the setting name.
  • code --update-setting <name> <value> could modify setting name with the new value. Since values can be complex JSON objects, this interface may need additional inputs (e.g., file and/or STDIN).

Alternatives Considered

One could attempt to parse settings.json manually, but will soon find that VSC JSON doesn't follow any specification, as it supports:

  • Comments
  • Trailing commas
  • Single quotes
  • ... and more

Looking at the source code, the parser appears to be custom and doesn't seem to follow a spec of any kind. While there is jsonc-parser package, it also has a few flaws:

  • It's not actually used by VSC, so parsing of valid (according to VSC) settings.json might fail
  • It requires end user to use NodeJS. What if user is writing a simple automation with Python or bash?
  • It enables you to specify invalid values for settings (e.g., a string where the list is expected)

Having Settings functionality exposed via CLI interface, circumvents the problem of parsing - and enables users to both configure VSC from CLI and build automations however they like.

I have nothing to add on top of it. I just think that it's a shame that, since it failed to reach 20 votes in the time necessary and was locked, I can't upvote it to show interest. I understand that locking issues to prevent +1 comment spam and to clear out the log of open issues is good for project tidiness, but surely if interest mounts, then it might be worth considering for reopening?

I apologize if creating this issue is a violation of the contributing guidelines. I could not find anything in its text about trying to make new issues for old, closed FRs, so hopefully this is kosher. Nothing had seemingly linked to it, either, so at the very least I've tried not to make a duplicate of a duplicate.

Metadata

Metadata

Assignees

Labels

*duplicateIssue identified as a duplicate of another issue(s)

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions