Showing content from https://phabricator.wikimedia.org/T394964 below:
⚓ T394964 Allow customization of Stylelint and ESLint rules in CodeMirror
Adjacent to T394965: Add call to action to perform server-provided linting of JS, CSS and wikitext 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
Event Timeline Comment Actions
Add some sort of comment-based annotation to tell CodeMirror which style to use.
CodeEditor's JSHint allows in-page customization of linter rules using comments like /* jshint esversion:10 */ and similar. I think the same will be possible with ESlint?
Alternatively, it could be stored as page prop
Page props are an artifact of parsing. So you'll need some kind of annotation in the text to begin with.
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4