Add support for Ember's new .gjs/.gts file format to SonarJS

Rules and Languages New rules / language support
, ,
1

For some background, historically Ember.js has used regular .js/.ts files for all of its javascript, and .hbs (handlebars) files for it’s templates, because it used regular .js/.ts files for its javascript, sonar analysis worked out of the box with no problems.

With the latest changes to the framework a new file format has been proposed that combines javascript and handlebars inside a single file, the new file format RFC first-class-component-templates has already been accepted and this is the direction in which the framework will be moving too.

This new file format is already available for use on existing projects via the ember-template-imports addon for Ember, and it will be the default format in future Ember edition.

Here is an example of a .gjs file:

import Component from '@glimmer/component';
import { tracked } from '@glimmer/tracking';
import { on } from '@ember/modifier';

// components/hello.gjs
export default class Hello extends Component {
  @tracked count = 0;

  increment = () => {
    this.count += 1;
  };

  decrement = () => {
    this.count -= 1;
  };

  <template>
    <button {{on "click" this.increment}}>+</button>
    Count: {{this.count}}
    <button {{on "click" this.decrement}}>&minus;</button>
  </template>
}

Basically it is a combination of javascript and handlebars syntax inside the same file, and .gts is the same just written in typescript.

It would be nice if we could add support for .gjs/.gts inside of SonarJS, the same way we now have support for .vue files.

There is already a gjs-gts-parser available which we can add to existing eslint parsers inside of SonarJS.

10 Likes
3

Hi @stefanoviv,

Welcome to the community! Thank you for your request. Our PM for SonarJS is away at the moment. I have flagged your request so that he will see it when he returns.

John

2 Likes
6

Thank you @john.clifton

I actually went ahead and created a PR that implement this feature in your repository Add support for ember gjs/gts file format by vstefanovic97 · Pull Request #4504 · SonarSource/SonarJS · GitHub, I would appreciate if this would be considered and reviewed by your engineers. I’m open to working on this and fixing any problems or concerns

Even though Ember.js is not as popular as React, Vue etc. It still has a solid community and people are still using it commercially especially on big projects and I think it makes sense to try and continue to support it as all those people are potential customers :smiley:

Thank you in advance

2 Likes
10

Hi it’s been 2 weeks already since I created a PR for this, can I get any sort of feedback on it?

11

Hello @stefanoviv,

Sorry for taking this long to answer you.

Thank you so much for your feature request and the effort you put into exploring the SonarJS codebase to introduce support for Ember.js. We genuinely appreciate the time and dedication you’ve invested in contributing to our analyzer.

After careful consideration, I am sorry to tell you that we are unable to accept your contribution for Ember.js support at this time. Introducing support for a new framework goes beyond syntax parsing; it involves long-term maintenance, keeping up-to-date with additional dependencies, and adjusting rule behavior to align with the framework’s specificities.

Our current bandwidth doesn’t allow us to dive into this extra workload. That being said, we’re always open to community input, and if there’s a growing demand for Ember.js support down the road, we’ll happily reconsider our position.

Hope this helps,
Yassin

2 Likes
12

Thank you @Yassin I appreciate your honest response.

Unfortunately right now our company is using sonar for our ember project and this is sort of blocking us from using Ember’s new syntax.

We will probably opt to forking sonarjs and using the fork as a custom plugin.
On that topic are there any plans to add an option to disable sonarjs as a default plugin?
Right now I sort of just do

#disable Default SonarJS plugin
sonar.javascript.exclusions=**/**
sonar.typescript.exclusions=**/**
sonar.lang.patterns.ts=""
sonar.lang.patterns.js=""

To disable it, and rename all of the keys in my fork to something else to not cause conflicts, it is a pretty hacky solution, but it seems to do the trick. Having some stable API for this would be great.

From what I can see right now you only support Angular, React and Vue there are lots of frameworks (like for example Svelte) and some others that could probably benefit from being able to use a SonarJS fork and just add their eslint parser.

Would you maybe consider adding an option to turn off the plugin if someone wants to use a fork?

13

Thank you for looking into this request!

It would be frustrating if this can’t land.
As Vuk mentioned, currently there is even no way to integrate such kind of feature on top of SonarJS.

We understand your team may not want to commit for Ember.js support due to relatively lower demand. However, currently there does not seem a way for community to add such support in user land e.g. by creating SonarQube plugin that will provide support for Ember.js in a way that integrateswith SonarJS (rather than replaces it).

If you don’t want to commit to support Ember.js now, please create an API in SonarJS so community could create a plugin that will utilize that API to provide custom parser for various file extensions.
It even could add support for GraphQL via https://www.npmjs.com/package/@graphql-eslint/eslint-plugin

That way, support for Svelte, Ember.js, Angular SFC (if they happen) could be easily added by community and e.g. Ember.js community could support that plugin which would just integrates with SonarQube via SonarJS.

Currently, the only way to add Ember.js support in SonarJS seem to be only by:

  • disabling built-in SonarJS plugin
  • forking SonarJS plugin, adding support for Ember.js
  • keeping fork up to date
  • installing plugin from fork in the SonarQube

As I imagine, custom plugin would “register” custom extension(s) in SonarJS plugin and provide parser for those extensions. So we could have central way of setting up rules for JavaScript and all of its flavours used in project.

Please, reconsider accepting this feature request as bulk of work already was done in Add support for ember gjs/gts file format by vstefanovic97 · Pull Request #4504 · SonarSource/SonarJS · GitHub and there is no other proper alternative available.

Thank you in advance!

14

Hello folks,

Indeed, Ember.js is not a priority for us at this time since the user base is relatively low and retention is dropping a bit. We want to use our limited energy to serve the majority of developers.

Whenever we can accommodate, we are happy to. In this case, this introduces a new parser, which has ramifications. There are no plans for this at this point.

Coming back to your needs:

…the only way to add Ember.js support…

…there is no other proper alternative available…

Sonar already provides a way to incorporate third-party issues, please see:

Did you consider this? It seems a much simpler solution for your use case.

Or is there some other reason you cannot use this for your current needs?

15

yes, we looked into “Importing third-party issues” and that does seem to be a complete solution.

We could run eslint -f json on .gjs/.gts files and then feed the result to SonarQube via sonar.eslint.reportPaths property.
But how can we tell SonarQube scanner to include .gjs/.gts files in index?

Then how would we configure SonarQube to parse .lcov files for those gjs/.gts files? Currently, this is done via sonar.javascript.lcov.reportPaths which is property for SonarJS plugin.

As your team don’t want to commit for Ember.js support, please advise how this could be done in a way that would result in a consistent experience.

16

the user base is relatively low and retention is dropping a bit

StateOfJS has never been representative of anything. Its issues are well known. Our user base is low but growing, and investment into the framework and the community remains stable.

In this case, this introduces a new parser, which has ramifications. There are no plans for this at this point.

It does not introduce a parser that sonarjs needs to support.

Ember.js is not a priority for us

This is sad to hear. Ember represents a large number of top-tier SAAS and financial applications. And it seems this would force us to stop using sonarcloud enterprise.

2 Likes
17

Normally, when you build your own plugin, you just need to put the jar to the extensions/plugins/ directory of your SonarQube installation. However, in your case, you will need to replace the JavaScript jar with your fork’s in the lib/extensions directory.

Please let me know if that works :slight_smile:

21

Hi @runspired,

I’m sorry this is disappointing.

This might change in the future, but we are not ready to commit to any plans.

Right now, Sonar offers a way to import external issues and this should work for the use cases evoked here.

23

Thank you @Yassin, this actually worked.

I ended up building a custom image where I swap the libs

Example

FROM sonarqube:9.9.1-community

USER root

RUN rm -rf /opt/sonarqube/lib/extensions/sonar-javascript-plugin-*

USER sonarqube

COPY sonar-plugin/sonar-javascript-plugin/target/sonar-javascript-plugin-10.12.0-SNAPSHOT-darwin-arm64.jar /opt/sonarqube/lib/extensions

And it seems to work just fine w/o any issues at least on my local machine, we will probably try to integrate this in our CI soon.
I will make the fork public on github so others can do the same, but this only helpr people that run their own Sonarqube instance, I guess if someone is using sonarcloud this isn’t possible?

1 Like
24

For transparency here is the link to the fork Commits · vstefanovic97/SonarJS · GitHub, I’ve updated the Readme in case any ember dev wants to try this out

2 Likes