Skip to content

Add extension setting field for indicating it may be influenced by a deprecated/renamed setting #91618

@Colengms

Description

@Colengms

We'd like to rename some settings in our extension, without having to rewrite users settings files. We'd like to use deprecationMessage, and would like to fall back to the old setting if the new setting is not set (by using WorkspaceConfiguration.inspect()). I believe we would need a minor addition in order to make the settings UI more user-friendly when renaming settings and falling back to old settings when not present.

Could we get an additional field in package.json for settings (configuration.properties), with which we can specify a deprecated setting that may influence the (new) setting if unset/default? In settings UI, display an additional message for the new setting indicating its effective value may be influenced by a deprecated setting (and perhaps a link to the deprecated setting, and a button to remove the deprecated setting value). For example, in the case below the effective value of the setting will be "Enabled" because the old setting is set to "Enabled", and the new setting is unset (It's default is "EnabledIfIncludesResolve", which is displayed also when the setting is unset, but is not the setting we would use).

image

image

Showing this message is a simple solution. A more complicated solution might be to somehow reflect in the new setting what the effective value is when unset. But, it's conceivable that a newer setting does not map directly to a deprecated setting, or perhaps multiple deprecated settings may influence the behavior of a new setting, or there is otherwise not a clear relationship between old and new settings.

You might also consider not showing a deprecated setting in settings UI when there is an associated newer setting (and it is set to something). And, perhaps store the default value (instead of clearing out the value, which is the current behavior) if a newer setting (with associated deprecated setting(s)) becomes set to its default value via the UI.

I might be over thinking this, but I've tried a number of approaches. If there is a proper way to deprecate settings and fall back to them when new settings are not present, that does not break the setting UI experience, please let me know.

Metadata

Metadata

Assignees

Labels

feature-requestRequest for new features or functionalitysettings-editorVS Code settings editor issuesverification-neededVerification of issue is requestedverifiedVerification succeeded

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions