Add Glimmer JS language

[gilest]

Description

Adds support for Glimmer.js which will be the component authoring format of the next Edition of Ember.js.

Checklist:

• I am adding a new language.
  • The extension of the new language is used in hundreds of repositories on GitHub.com.
    • Search results for each extension:
      • .gjs 2.2k files excluding forks
  • I have included a real-world usage sample for all extensions added in this PR:
    • Sample source(s):
      • class.gjs
      • template-only.gjs
    • Sample license(s):
      • class.gjs - (https://github.com/discourse/discourse-ai) MIT
      • template-only.gjs (https://github.com/CrowdStrike/opensource.crowdstrike.com) MIT
  • I have included a syntax highlighting grammar:
    • https://github.com/lifeart/vsc-ember-syntax – MIT
  • I have added a color
    • Hex value: #F5835F
    • Rationale: Logo colour from https://glimmerjs.com/ at time of writing

[gilest]

@lildude would you mind running the CI for me? Want to make sure I didn't make a mistake this time 😅

Never mind – got it running in my fork ✅

Believe we are now meeting the usage requirements, too 🎉

[NullVoxPopuli]

really excited for this! looks like we're no longer "Pending Popularity"

[lildude]

really excited for this! looks like we're no longer "Pending Popularity"

Not quite. Excluding forks drops things down to ~1.8k.

[NullVoxPopuli]

Not quite. Excluding forks drops things down to ~1.8k.

can we include markdown which references gjs? (that's at 2k 🥳 )

update: we're over 2k non-markdown files now :D

[wagenet]

@lildude It looks like gjs without markdown and excluding forks is now at 2k.

[lildude]

Heads up: this language won't be using the most up-to-date version of the grammar when it is released to GitHub as a duplicate scope has been added to that repo since this PR was created.

- [ ] repository `vendor/grammars/Handlebars` (from https://github.com/daaain/Handlebars) (1 errors)
  - Duplicate scope in repository: scope `text.html.handlebars` was already defined in repository `vendor/grammars/vsc-ember-syntax` (from https://github.com/lifeart/vsc-ember-syntax.git)

vendor/grammars/Handlebars has priority as it was here first and is dedicated to the language.

[lildude]

Actually, now I look at this more closely, it appears this grammar was added with that conflict already in place suggesting script/add-grammars wasn't used or the addition was forced and the error ignored. Reverting this PR.

Please resubmit when the issue with the upstream grammar has been fixed.

[NullVoxPopuli]

Is there a way to tell vsc-ember-syntax to take precedence over daaain/Handlebars?

afaict, The upstream grammar is correct for ember users, and no ember user should ever be using daaain/Handlebars (only a file extension is shared, and nothing more)

For ember projects using the .hbs extension, "Handlebars" is just the wrong syntax. There are specific file differences we could query for in package/workspace boundaries to determine if a project/package/workspace is an ember project or not, but does linguist respect that sort of querying?

[gilest]

Actually, now I look at this more closely, it appears this grammar was added with that conflict already in place suggesting script/add-grammars wasn't used or the addition was forced and the error ignored. Reverting this PR.

Please resubmit when the issue with the upstream grammar has been fixed.

Oh, sorry about that 😓 . I used script/add-grammars but then manually removed text.html.handlebars from vsc-ember-syntax in grammars.yml to avoid conflicting with the existing Handlebars grammar. Figured since the CI passed that was ok...

We discussed this in the public feedback PR before this one was raised.

Is there any way to proceed without removing handlebars from the upstream grammar? It's needed for in-editor support of Ember-flavoured handlebars. But ideally it's ignored in Linguist... 😅

[lildude]

Is there a way to tell vsc-ember-syntax to take precedence over daaain/Handlebars?

Not really. Linguist, more specially the highlighting engine, only has support for one grammar scope per language and it doesn't have a mechanism for overriding. Generally grammars inherit and extend upon other grammars using a different scope name if they want something to behave differently from the original grammar.

The closest option to forcing is by replacing the current Handlerbars grammar with that supplied by vsc-ember-syntax. This comes with the consequence that that project will now be responsible for the syntax highlighting of all handlebar files, not just Ember users.

afaict, The upstream grammar is correct for ember users, and no ember user should ever be using daaain/Handlebars (only a file extension is shared, and nothing more)

For ember projects using the .hbs extension, "Handlebars" is just the wrong syntax.

And there's the problem. If the file and syntax is not handlerbars, the grammar should not be using the same scope name. It should be using its own scope and either completely defining everything it supports or inheriting from the handlebars grammar and overruling the differences. This is common practice.

There are specific file differences we could query for in package/workspace boundaries to determine if a project/package/workspace is an ember project or not, but does linguist respect that sort of querying?

Not unless there's something in the files themselves that is unique to ember. Linguist looks at files in isolation (think gists) to try and determine the language which is then fed to the highlighting engine.

If the files are definitely not handlebars and should have their own grammar, then they can be added to linguist as their own language but the grammar will still need to use a unique scope name.

[lildude]

Is there any way to proceed without removing handlebars from the upstream grammar? It's needed for in-editor support of Ember-flavoured handlebars. But ideally it's ignored in Linguist... 😅

Yes, however that's just painting over the problem and incorrect behaviour I just highlighted above.

[gilest]

@lildude Appreciate your counsel on this.

We've updated the upstream grammar to correctly use a unique scope for "ember-flavoured" handlebars – text.html.ember-handlebars

Re-staged in #6630