Inconsistent behavior between rule ID (MD013) and rule name (line-length) in config overrides

[jotabe-net]

I'm encountering a confusing behavior when configuring markdownlint in VS Code using both workspace and user settings.

In my user settings, I had:

"markdownlint.config": {
  "line-length": {
    "line_length": 80,
    "code_blocks": false,
    "stern": false,
    "tables": false
  }
}

In my workspace settings, I tried to disable the rule using:

"markdownlint.config": {
  "MD013": false
}

Despite the workspace setting, the rule was still being applied. After investigation, I realized that, for overriding rules, "MD013" and "line-length" are treated as distinct keys, even though they refer to the same rule.

If I change the workspace to "MD013" or the global "line-length" to "MD013" they are correctly overridden.

I was encountering some other weird behavior, for ex. if i included this in workspace settings.json: "markdownlint.configFile": ".markdownlint-cli2.jsonc", the workspace settings did override the "MD013".

I think that making the long and short names equivalente for overriding would solve all the quirks.

[DavidAnson]

The behavior of what overrides what other things should be deterministic and I think generally later things replace earlier things, but I couldn't describe all the nuances without looking at the code. That said, I wouldn't really recommend the approach you describe of having three or more overlapping configurations. In the VS Code extension, user settings are meant for people who want the same behavior everywhere and may not be working in project. Workspace settings are obviously for people using workspaces. And file-based configuration within that workspace or project is what I ultimately recommend because it automatically applies for other users of that project and also works outside the VS Code editor with tools like the CLI.

Regarding your comment about configuring the same rule by multiple names, I think the override behavior is independent of that and you will find that a particular configuration works the same regardless of what name is used for a rule. If you think you are seeing something else, please outline the specific steps to reproduce that and I can have a look.

[jotabe-net]

I agree on your analysis regarding the overriding at different levels. That said, this is my formal "bug description":

Expected behavior

If I set a rule in user settings, and in worskpace settings, I expect that the workspace settings override the user settings.

Real behavior

If I set the same rule in user settinga and workspace settings, but using different names, the workspace settings don't override the user settings.

Steps to reproduce

For example "MD013" and "line-length" refer to the same rule.

Setting this in user settings:

"markdownlint.config": {
  "line-length": {
    "line_length": 80,
    "code_blocks": false,
    "stern": false,
    "tables": false
  }
}

And setting this in workspace settings

"markdownlint.config": {
  "MD013": false
}

Should result in this rule being disabled, but if you type a line longer than 80 chars, the "MD013" rule warning is triggered.

If you change the settings to use either of the names in both settings, the rule is overridden as expected.

[DavidAnson]

The VS Code API for getting user/workspace settings merges same-named objects, so we can simplify the scenario above as follows:

"markdownlint.config": {
    "MD013": false,
    "line-length": true,
}

Notably, the configuration for the rule that checks line length under the name line-length enables it and the configuration for it under the name MD013 disables it. As you report, the observed behavior is that the rule is enabled. That's because the behavior of the markdownlint library when applying configuration for the same rule first applies by identifier (MD013) and then by name (line-length). So the configuration for line-length takes precedence. The fact you're doing this across different files is not relevant. And the order of the two configurations is also not relevant (in this scenario; if using the same name in both cases, then the latter definition takes precedence). You can verify this experimentally.

This particular choice of precedence is somewhat arbitrary, but it is stable, so behavior of the library/extension is consistent. Flipping the precedence is possible, but no more clearly right or wrong. Therefore, no change to the implementation seems appropriate.