[JavaScript] Uppercase constant gets support.class.js scope

[alecmev]

What happened?

With this code:

const FOO = 'foo'
console.log(FOO)
console.log(FOO.toUpperCase())

I get the following result:

Due to this part:

Packages/JavaScript/JavaScript.sublime-syntax

Lines 2087 to 2089 in e76cf75

	- match: '{{constant_identifier}}(?=\s*(?:{{dot_accessor}}|\[))'
	scope: support.class.js
	pop: 1

I understand that the syntax engine doesn't have any idea what type it is, so it can only guess, but it's weird to see the same identifier have a different color depending on whether there's a dot after it or not. Could the heuristic be adjusted, perhaps? E.g. have CONSTANT_CASE identifiers be always treated as variable.other.constant.js, and all CamelCase PascalCase as support.class.js?

Also, how does VSC handle this?

Can ST do that?

[michaelblyons]

Also, how does VSC handle this?

I don't know if this is an instance of it, but VSC runs a second, completely different tokenizer after the main one that tweaked the scopes a little bit more. It was (may still be?) asynchronous, and you'd sometimes see the code change colors when you opened certain files.

[jfcherng]

Also, how does VSC handle this?

I don't know. But when people are amazed by VSCode's syntax highlighting, I will guess they all comes from language server's semantic highlighting. VSCode's highlighting engine is inferior to ST's but semantic highlighting from plugins are usually perfect accurate.

and all CamelCase as support.class.js?

Is this an official standard or de facto standard in JS? UPPER_CASE = constants seems to be widely adopted as a naming convention in various languages though.

[alecmev]

and all CamelCase PascalCase as support.class.js?

Is this an official standard or de facto standard?

Very little is official about JavaScript 😅 But I don't remember ever seeing any real-life projects or style guides that use PascalCase for anything but classes, components, enums, interfaces, types. Does anybody have any counter-examples?

https://eslint.org/docs/latest/rules/new-cap
https://github.com/airbnb/javascript#naming--PascalCase
https://standardjs.com/rules.html (look for new-cap)
https://arcticicestudio.github.io/styleguide-javascript/rules/naming_conventions.html#pascalcase
https://khalilstemmler.com/blogs/camel-case-snake-case-pascal-case/#Pascal-case
https://github.com/xojs/eslint-config-xo/blob/8fe0949b681160f003572c1bdc1c505319409d34/index.js#L366-L372
https://google.github.io/styleguide/jsguide.html#naming-class-names

[jfcherng]

I asked that mainly because for Python, there is PEP 8 official guide for variable naming. However, ST doesn't scope variable, class, function etc... by that standard naming convention. Well, in fact people have their own taste so not all people follow PEP 8.

So, if it's not even an official standard for JS, I doubt that will work here. But I do agree that it's rare that a PascalCase thing is not a class.

[alecmev]

From my experience, "PascalCase = abstraction/namespace" has comparable level of certainty to "SCREAMING_SNAKE_CASE = constant" in the JavaScript/TypeScript world.

[Thom1729]

I agree that it's weird that FOO and FOO.toUppercase() have different highlighting. I suspect that this is inadvertent — that the rule is intended for e.g. Foo.toUpperCase(), but FOO matches constant_identifier.

[jwortmann]

The same discussion was recently on the forum for Python, and I suggested that the PascalCase heuristic could be used to highlight identifiers as class name: https://forum.sublimetext.com/t/incorrect-syntax-with-python-for-none-type-hints/64640/12.
There is already a precedent witht the highlighting on GitHub which seems to use this heuristic, but it was more or less rejected because relying on casing for highlighting apparently is/was one of the most popular reasons for bug reports. Which is kind of contradictory to that the UPPER_CASE heuristic is already used for constants in many syntaxes, but well....

Can ST do that?

If you use LSP and LSP-typescript, and enable semantic highlighting in the LSP settings, then it should give (almost) similar highlighting as in VSCode, which I think uses the same language server. There are a few limitations compared to VSCode, for example italic font style doesn't work, and you may need to tweak your color scheme (see LSP docs) if you want to achieve certain highlighting colors rather than what's defined as default by LSP - see in the screenshot below that it used different colors based on whether something is a declaration or usage, but in general the token type (function, constant, class) is recognized correctly.