Update Tutorial for JS/TS projects Scanning

  • which versions are you using (SonarQube Community Build version 25.5.0.107428)
  • how is SonarQube deployed: zip
  • what are you trying to achieve: update the tutorial command to include project key in parameter
  • what have you tried so far to achieve this: I have forked and cloned sonar-webapp repo and updated the code locally after performing the necessary steps listed in the sonar-developer-toolset repository.

When scanning a JavaScript or TypeScript project using the SonarQube Community Build (version 25.5.0.107428), the instructions typically suggest installing an NPM package, followed by executing the following command:

sonar -Dsonar.host.url=http://localhost:9000 -Dsonar.token=sqp_xxxxx

If you run the command as-is, it will fail — likely with an error saying you’re not authorized to analyze or create the project.

[ERROR] ScannerEngine: You’re not authorized to analyze this project or the project doesn’t exist on SonarQube and you’re not authorized to create it. Please contact an administrator.
[ERROR] Bootstrapper: An error occurred: Error: Scanner engine failed with code 1

The fix is straightforward: just add the missing project key. For example:

sonar -Dsonar.host.url=http://localhost:9000 -Dsonar.projectKey=full-stack-fastapi-template -Dsonar.token=sqp_xxxxx

1 Like

I’ve created a pull request at the repository. Please do let me know if I’m missing something necessary as I don’t have much experience in contributing to projects. :eyes:

1 Like

Hello @sonarsourcedetention ,
Welcome to the Sonar Community!

Thanks a lot for your contribution. We will take care of your PR.

Cheers,
Javier

1 Like

Hi @sonarsourcedetention ,

I checked this out with the web team and they replied:

the npm scanner usually takes the projectKey from the package.json file, using the name field for it. If it fails for the user, it means he probably does not have a package.json file. Indeed, if this is the case, he should specify it via cli..

Does this make sense in your case?

Cheers,
Javier

Hello Javier,

Thanks for checking it out. The package.json is there in the frontend directory. The example below is performed in the frontend directory of the full-stack-fastapi-template project cloned from GitHub.

Does it mean that the projectKey has to be manually defined in the package.json file for JS/TS web project?

Hi @sonarsourcedetention ,

As far as I understood from my colleague’s comment: the name field in the package.json file is used as the projectKey. When you pass the -Dsonar.projectKey in the command line I guess that value is overridden and that’s why it works.
I would try to change the value from frontend to full-stack-fastapi-template here: full-stack-fastapi-template/frontend/package.json at master · fastapi/full-stack-fastapi-template · GitHub

Cheers,
Javier

Hi Javier,

I get that the projectKey is automatically retrieved from the package.json. It’s just sometimes the user might not just create a project with the exact name as defined in the package.json. For example, this full-stack-fastapi-template project contains multiple directories like frontend and backend with code in different languages.

If the user intends to analyze the whole repository in one SonarQube project, wouldn’t the user tends to create something like full-stack-fastapi-template?

If the user intends to analyze the directories separately and upload to different SonarQube projects, would the user tends to create something like full-stack-fastapi-template-frontend as the projectKey instead of frontend?

Also, the suggestion for the other type of projects tend to include project key and project name. It might be easier for new user if the tutorial is standardized a bit. :grinning_face:

Maven - projectKey and projectName
Gradle - projectKey and projectName
JS/TS Web -
.NET - projectKey
Other (for Go, Python, PHP, …) - projectKey

Anyway, is there any concern of not encouraging the users to use a different projectKey than the one defined in the package.json? Like causing problems to the other parts of the code.

Hi @sonarsourcedetention ,

I’ll try to answer all your questions one by one:

If the user intends to analyze the whole repository in one SonarQube project, wouldn’t the user tends to create something like full-stack-fastapi-template?

Yes, this completely makes sense. In fact, I made a test in sonarcloud.io. To run the analysis I used the Other (for Go, Python, PHP,...) option:


This runs the sonar-scanner of all the subprojects, frontend and backend, when you run it from the root folder.

If the user intends to analyze the directories separately and upload to different SonarQube projects, would the user tends to create something like full-stack-fastapi-template-frontend as the projectKey instead of frontend?

Yes, but then there are two options:

  1. Modify the name in the package.json file to be aligned with the SonarQube project
  2. Use the -Dsonar.projectKey when running the analyzer.

I understand that the tutorial is a bit confusing if you try to find some similarities between the different options but I think that there is no relationship between them. I mean, it depends on the shape of your project and how you want to analyze it, the way you have to run the analyzer.
However, the team is going to improve the JS/TS & Web section to add the possibility to override the projectKey using the -Dsonar.projectKey as you mentioned. Thanks again for your contribution.

Anyway, is there any concern of not encouraging the users to use a different projectKey than the one defined in the package.json? Like causing problems to the other parts of the code.

Nope. The projectKey is used for the authentication at the same time than the token, independently if it is taken from the package.json or the -Dsonar.projectKey parameter. This value must match the project name in SonarQube, otherwise a non authorized error is produced.

I hope I solved your doubts.

Cheers,
Javier

Hi Javier,

Yes, this completely makes sense. In fact, I made a test in sonarcloud.io. To run the analysis I used the Other (for Go, Python, PHP,...) option:

This runs the sonar-scanner of all the subprojects, frontend and backend, when you run it from the root folder.

Thanks for sharing about this option. I didn’t know it would try to detect and run the code in different languages nicely, definitely would try it out :grinning_face:

Yes, but then there are two options:

  1. Modify the name in the package.json file to be aligned with the SonarQube project
  2. Use the -Dsonar.projectKey when running the analyzer.

I understand that the tutorial is a bit confusing if you try to find some similarities between the different options but I think that there is no relationship between them. I mean, it depends on the shape of your project and how you want to analyze it, the way you have to run the analyzer.
However, the team is going to improve the JS/TS & Web section to add the possibility to override the projectKey using the -Dsonar.projectKey as you mentioned. Thanks again for your contribution.

Thanks a lot for the explanation — that clears things up. I’m really glad if my suggestion was helpful in any way. I fully understand and respect the design choices, and just wanted to contribute a small thought. Appreciate the response and all the work you’re doing — thanks again!

Nope. The projectKey is used for the authentication at the same time than the token, independently if it is taken from the package.json or the -Dsonar.projectKey parameter. This value must match the project name in SonarQube, otherwise a non authorized error is produced.

Understood on this part. All my doubts are cleared. Thanks again for looking in to this. Have a nice day/evening :grinning_face:

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.