In both JavaScript and Lua, there are built-in globals independent of the environment, such as String in JavaScript and tostring in Lua. These variables or functions should be distinct from other variables or functions.
Description
Description
Details
Details
Related Changes in Gerrit:
| Subject | Author | Repo | Branch | Lines +/- | |
|---|---|---|---|---|---|
| JavaScript and Lua modes: highlight built-in globals | Bhsd | mediawiki/extensions/CodeMirror | master | +168 -24 |
Event Timeline
Comment Actions
Change #1232588 had a related patch set uploaded (by Bhsd; author: Bhsd):
[mediawiki/extensions/CodeMirror@master] JavaScript and Lua modes: highlight built-in globals
Comment Actions
Thanks for investigating this. But I disagree that environment-specific globals need not be highlighted. As long as browser globals are set to be recognized as they already are, I don't see why not. Couldn't they be dynamically (de)highlighted to reflect config.env?
Comment Actions
You are essentially requesting a standalone ESLint legacy configuration parser. Besides, the browser globals alone costs ~20 kb after minification.
Comment Actions
My assumption was that browser: true and es2024: true make it recognize more globals so CM already has a list of them somewhere. That's not the case?
Comment Actions
No. Unfortunately, ESLint API that exposes resolved configuration depends on the file system and cannot be browserified. The only API endpoint we are browserifying is the Linter class which has no access to the configuration resolved internally (ref).
Comment Actions
Change #1232588 merged by jenkins-bot:
[mediawiki/extensions/CodeMirror@master] JavaScript and Lua modes: highlight built-in globals