Start adopting unified js/ts config for code lenses by mjbvz · Pull Request #294264 · microsoft/vscode

mjbvz · 2026-02-11T00:15:12Z

Testing this with a self contained area first: code lenses. Will keep support for the old setting values too to avoid breaking existing settings

For microsoft#292934 Testing this with a self contained area first: code lenses. Will keep support for the old setting values too to avoid breaking existing settings

Copilot

Pull request overview

This PR starts adopting a unified js/ts.* configuration namespace for the TypeScript/JavaScript CodeLens settings in the typescript-language-features extension, while preserving support for the legacy javascript.* / typescript.* settings via fallback logic.

Changes:

Added new helper utilities to read unified js/ts settings with fallback to the legacy language-specific sections.
Updated references/implementations CodeLens providers to use unified settings and react to unified configuration changes.
Introduced new js/ts.* CodeLens settings in package.json and deprecated the legacy settings with updated NLS strings.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
extensions/typescript-language-features/src/utils/configuration.ts	Adds shared unified-config read/inspect helpers for `js/ts.*` with fallback logic.
extensions/typescript-language-features/src/languageFeatures/util/dependentRegistration.ts	Adds a new conditional registration helper based on unified/legacy config modification detection.
extensions/typescript-language-features/src/languageFeatures/codeLens/referencesCodeLens.ts	Switches references CodeLens to unified settings + adds early-return based on unified enablement.
extensions/typescript-language-features/src/languageFeatures/codeLens/implementationsCodeLens.ts	Switches implementations CodeLens to unified settings + adds early-return based on unified enablement.
extensions/typescript-language-features/package.nls.json	Replaces per-language CodeLens setting strings with unified descriptions + deprecation messages.
extensions/typescript-language-features/package.json	Adds `js/ts.*` CodeLens settings and marks legacy settings as deprecated.

Comments suppressed due to low confidence (1)

extensions/typescript-language-features/src/languageFeatures/util/dependentRegistration.ts:110

The doc comment says this checks modifications in “either the global or workspace scope”, but hasModifiedUnifiedConfig/hasModifiedValue also considers workspace-folder and language-specific overrides. Please update the comment to match the actual behavior (or narrow the implementation to what’s documented).

/**
 * Requires that a configuration value has been modified from its default value in either the global or workspace scope
 *
 * Does not check the value, only that it has been modified from the default.
 */

extensions/typescript-language-features/src/utils/configuration.ts

Copilot · 2026-02-11T00:25:46Z

extensions/typescript-language-features/src/languageFeatures/util/dependentRegistration.ts

+export function requireHasModifiedUnifiedConfig(
+	configValue: string,
+	fallbackSection: string,
+) {
+	return new Condition(
+		() => hasModifiedUnifiedConfig(configValue, { fallbackSection }),
+		vscode.workspace.onDidChangeConfiguration
+	);


requireHasModifiedUnifiedConfig registers the CodeLens provider when the setting is merely modified, even if it’s explicitly set to false (same as default). This means users can end up with the provider registered and queried even though it will always return no lenses. Consider making the condition check whether the setting is enabled in any relevant scope (unified or legacy), instead of just modified.

This issue also appears on line 106 of the same file.

We have a separate check for this in the provider

Copilot · 2026-02-11T00:25:46Z

extensions/typescript-language-features/src/languageFeatures/codeLens/referencesCodeLens.ts

 		switch (item.kind) {
 			case PConst.Kind.function: {
-				const showOnAllFunctions = vscode.workspace.getConfiguration(this.language.id).get<boolean>('referencesCodeLens.showOnAllFunctions');
+				const showOnAllFunctions = readUnifiedConfig<boolean>(Config.showOnAllFunctions, false, { scope: document, fallbackSection: this.language.id });
 				if (showOnAllFunctions && item.nameSpan) {
 					return getSymbolRange(document, item);
 				}


readUnifiedConfig calls getConfiguration().inspect() which is relatively expensive, and here it’s invoked inside extractSymbol while walking many navtree nodes. This can be a noticeable regression for large files. Consider caching these config values per document (or per provideCodeLenses call) so the inspect/get work happens once, not per symbol.

Copilot · 2026-02-11T00:25:47Z

...nsions/typescript-language-features/src/languageFeatures/codeLens/implementationsCodeLens.ts

 		// If configured, show on interface methods
 		if (
 			item.kind === PConst.Kind.method &&
 			parent?.kind === PConst.Kind.interface &&
-			cfg.get<boolean>('implementationsCodeLens.showOnInterfaceMethods', false)
+			readUnifiedConfig<boolean>('implementationsCodeLens.showOnInterfaceMethods', false, { scope: document, fallbackSection: this.language.id })
 		) {
 			return getSymbolRange(document, item);
 		}


 		// If configured, show on all class methods
 		if (
 			item.kind === PConst.Kind.method &&
 			parent?.kind === PConst.Kind.class &&
-			cfg.get<boolean>('implementationsCodeLens.showOnAllClassMethods', false)
+			readUnifiedConfig<boolean>('implementationsCodeLens.showOnAllClassMethods', false, { scope: document, fallbackSection: this.language.id })
 		) {


readUnifiedConfig (which uses inspect) is called for each candidate symbol while traversing the navtree. For large files this is avoidable overhead compared to reading config once. Consider caching the relevant settings per document (e.g. enabled, showOnInterfaceMethods, showOnAllClassMethods) so these checks don’t re-run inspect repeatedly.

Copilot · 2026-02-11T00:25:47Z

extensions/typescript-language-features/package.json

+          "js/ts.implementationsCodeLens.enabled": {
+            "type": "boolean",
+            "default": false,
+            "description": "%configuration.implementationsCodeLens.enabled%",
+            "scope": "language-overridable",
+            "tags": [
+              "JavaScript",
+              "TypeScript"
+            ]
+          },


The js/ts.implementationsCodeLens.* settings are tagged for both JavaScript and TypeScript, but the descriptions say they apply to “TypeScript files”. If implementations CodeLens is still TS-only, the tags/description should be adjusted to avoid advertising this as a JS setting (or expand the implementation/docs to clearly support JS too).

Copilot · 2026-02-11T00:25:47Z

extensions/typescript-language-features/src/languageFeatures/codeLens/referencesCodeLens.ts

+	override async provideCodeLenses(document: vscode.TextDocument, token: vscode.CancellationToken): Promise<ReferencesCodeLens[]> {
+		const enabled = readUnifiedConfig<boolean>(Config.enabled, false, { scope: document, fallbackSection: this.language.id });
+		if (!enabled) {
+			return [];
+		}
+
+		return super.provideCodeLenses(document, token);
+	}
+
 	public async resolveCodeLens(codeLens: ReferencesCodeLens, token: vscode.CancellationToken): Promise<vscode.CodeLens> {
 		const args = typeConverters.Position.toFileLocationRequestArgs(codeLens.file, codeLens.range.start);
 		const response = await this.client.execute('references', args, token, {


New unified js/ts.* CodeLens settings are introduced along with fallback logic, but the existing smoke tests still only cover the legacy typescript.* keys. Please add coverage for the unified keys (including language-specific overrides) to ensure the precedence and fallback behavior stays correct.

Start adopting unified js/ts config for code lenses

0493189

For microsoft#292934 Testing this with a self contained area first: code lenses. Will keep support for the old setting values too to avoid breaking existing settings

Copilot AI review requested due to automatic review settings February 11, 2026 00:15

mjbvz enabled auto-merge February 11, 2026 00:15

Copilot started reviewing on behalf of mjbvz February 11, 2026 00:15 View session

vs-code-engineering bot assigned mjbvz Feb 11, 2026

vs-code-engineering bot added this to the February 2026 milestone Feb 11, 2026

DonJayamanne approved these changes Feb 11, 2026

View reviewed changes

Copilot AI reviewed Feb 11, 2026

View reviewed changes

mjbvz merged commit e2fdcd4 into microsoft:main Feb 11, 2026
22 of 23 checks passed

mjbvz mentioned this pull request Feb 12, 2026

Clean up JS/TS language specific setting settings #292934

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Start adopting unified js/ts config for code lenses#294264

Start adopting unified js/ts config for code lenses#294264
mjbvz merged 1 commit intomicrosoft:mainfrom
mjbvz:dev/mjbvz/long-meerkat

mjbvz commented Feb 11, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Copilot AI Feb 11, 2026

Uh oh!

mjbvz Feb 11, 2026

Uh oh!

Copilot AI Feb 11, 2026

Uh oh!

Copilot AI Feb 11, 2026

Uh oh!

Copilot AI Feb 11, 2026

Uh oh!

Copilot AI Feb 11, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

mjbvz commented Feb 11, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Copilot AI Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

mjbvz Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants