VSCodeの言語別設定は、複数設定すると優先度が落ちる仕様A quirk in VSCode's language-specific settings causes priority to drop…

Visual Studio Code allows developers to customize the editor on a per-language basis, so that, for instance, JavaScript files use two-space indentation while Go files use tabs. A recently shared Qiita post draws attention to a subtle quirk in how these language-specific settings are prioritized: when multiple entries are defined, resolution does not always follow the order a developer expects, and settings written later may not override those written earlier. For teams that depend on per-language overrides to enforce consistent formatting and editor behavior, this is a practical detail worth knowing.

Language-specific configuration in VSCode is written in settings.json using a bracketed language identifier as the key. A block such as "[javascript]" holds settings that apply only to files VSCode recognizes as JavaScript. These scoped entries take precedence over general, non-language settings, which is exactly what lets a globally defined editor.tabSize be selectively overridden for a given file type. The same layering applies across the configuration hierarchy, where default, user, workspace, and workspace-folder scopes stack in a defined order, with more specific scopes winning over broader ones.

The behavior described in the post concerns what happens once several language-specific blocks come into play. According to the report, adding multiple entries can cause the priority of a later definition to drop rather than rise, so that an override a developer intends to apply does not take effect. In other words, the mental model of "the last rule wins" does not reliably hold for these blocks. Because JSON objects do not guarantee that overlapping keys behave like a simple ordered list, the outcome can be counterintuitive, especially when the same setting appears in more than one place.

One common source of confusion is the combined-selector syntax, where a single key such as "[javascript][typescript]" applies the same block to multiple languages at once. This is convenient, but it changes how a setting is scoped compared with writing separate "[javascript]" and "[typescript]" blocks. When a combined selector and an individual selector both touch the same property, the resulting precedence may not match intuition, and it is easy to end up with a value other than the one most recently written. The safest approach appears to be avoiding the same property in overlapping selectors, and keeping each language's overrides in a single, clearly scoped block.

To diagnose these conflicts, VSCode offers tooling that makes the effective value visible. The Settings editor can be filtered by language using the "@lang:" filter, and inspecting a setting shows which