Adjacent to T394965: Provide API-powered linting of supported languages in CodeMirror

Background

T373711: Add support for Scribunto, JavaScript, CSS, JSON and Vue to CodeMirror 6 adds support for JS/CSS/JSON and Scribuntu. It also brought linting into the CodeMirror 6 ecosystem.

At the Wikimedia-Hackathon-2025, we spoke with the Editing team who asked us not to impose any stylistic preferences in our linters. So, for CSS we went with stylelint-config-recommended which primarily only prevents errors.

We are free however to allow users to opt-in to a coding style. The CodeMirror preferences system allows for this without adding more user options to the db, so I think the idea is worth exploring.

This idea applies to both Stylelint and the upcoming ESLint integration.

A collection of ideas

• Provide three options: "recommended" (default, only reports about violations prone to cause errors), "Wikimedia" (eslint-config-wikimedia and stylelint-config-wikimedia), and "custom" where you could provide a custom config via a JSON page.
• Perhaps introduce a config setting or MediaWiki JSON page so that entire wikis can impose a "default" linting style for each content model
• Add comment-based annotation to tell CodeMirror which style to use. This would allow folks to edit pages and not be given warnings just because their own personal code style preferences differ from what the script author desires.
  • Comment-based inline configuration is already supported, but it'd be better to be able to specify a style or link to a JSON page
  • For action=edit requests (not standalone CodeMirror), we could look for an expected subpage such as /eslint.json or at MediaWiki:Eslint-wikimedia.json etc. (and likewise for stylelint)
• For the sanitized-css content model, we could dynamically add Stylelint rules that are based on TemplateStylesMatcher, via a ResourceLoader virtual file. This wouldn't account for everything css-sanitizer does but it would prevent users from adding unsupported properties, units, colours, and other static analysis that can be easily configured in Stylelint. This would partially solve T190114 (assuming CodeMirror does replace CodeEditor).
• Prompt on save for actual errors that we know will break things or be blocked by css-sanitizer / Peast