No longer detecting TypeScript

SonarCloud
, ,
1

Template for a good new topic, formatted with Markdown:

  • ALM used - GitHub
  • CI system used - auto by sonarcloud
  • Scanner command used - via site
  • Languages of the repository - typescript
  • Only if the SonarCloud project is public - private

Since April 13-29 our account stopped processing TypeScript I’ve since deleted the project after trying multiple attempts to see if we’d borked the configuration and since then started it fresh and our 33k loc project has dropped to 171 loc javascript only.

New project fresh setup background task id. AXmOizvvYJIXlyrJv4E_

I’ve been looking around support for some time now trying to find a self resolution but don’t seem to be looking for the right thing or just not finding the answers I need. Potentially in relation to this issue based on other posts I’ve seen we added a babel.js to our project and changed tsconfig to allow for ‘fixed’ paths in project for imports … e.g., import Component from ‘/happiful/components/some-component’ and potentially this config is causing something to break in the auto detect? Either way we need some help please as none of our code seems to be getting processed.

Previous account background task id. AXmOY1aq_qivUHf3xuO-

2

Think this is resolved now just running some test but a little stealth change was added to tsconfig a few weeks ago by expo. It put extends: “expo/tsconfig.base” inside our tsconfig and this appears to have been enough to knock the whole detection process over.

Here is the contents of tsconfig.base can anyone explain whats so offensive about it?

{
"allowJs": true,
"esModuleInterop": true,
"jsx": "react-native",
"lib": ["DOM", "ESNext"],
"moduleResolution": "node",
"noEmit": true,
"resolveJsonModule": true,
"skipLibCheck": true
}

and here is what our tsconfig looks like after it was added.

{
  "compilerOptions": {
    "allowSyntheticDefaultImports": true,
    "jsx": "react-native",
    "lib": ["dom", "esnext"],
    "moduleResolution": "node",
    "noEmit": true,
    "skipLibCheck": true,
    "resolveJsonModule": true,
    "strict": true,
    "baseUrl": "src",
    "paths": {
      "happiful/*": ["./*"]
    }
  },
  "exclude": ["./node_modules/*"],
  "extends": "expo/tsconfig.base"
}

I’m guessing that either detector doesn’t like extends at all or specifically it can’t find expo/tsconfig.base ?

Any help on how to still use this extends but keep our quality control running at the same time would be hugely appreciated.

3

Welcome to the community!

In the scanner output corresponding to task AXmOY1aq_qivUHf3xuO-, I see this:

ERROR: File 'expo/tsconfig.base' not found.

Are you sure the path is correct?

4

Thanks for the response. Where do you see that output? When I’ve been looking in the background task context information there is no mention of error - at least in sonarcloud admin panel ui. In fact the line even says success on the listing for all background tasks.

As per my above reply I finally landed on that being the likely issue but it would have been super helpful if I were able to see it was a) erroring and b) why.

For a hotfix I’ve simply removed the above extends as I’m guessing it isn’t actually in node_modules and is only present on development machines because they have expo installed and is only required in development.

EDIT: Having said this outloud thats almost definitely the issue, I’m guessing when sonarscan node_moduels is completely empty as its not stored in the repo and is only populated on npm/yarn installs.

5

It’s in the output of the scanner. When using Autoscan, we execute the scanner on our infrastructure. Currently our users don’t have access to this log. Instead of exposing this log, our current strategy is to try to detect failures and show actionable error messages to help users resolve the problem. Looks like this case slipped through the cracks. I will signal to our analyzer developers and see how we can improve this.

You understand correctly. We only run the scanner, nothing else, for security reasons, for now. That’s why node_modules will not be there.

6

Thanks again.

My less hotfix, that i’m just testing now is to ensure those specific files are committed to repo and available for scanner to use.

8

That should work. For the record, we don’t recommend committing such files to version control.

9

To clarify I’m only committing specifically the node_modules/expo/tsconfig.base and not the entire node_modules - I can’t see another option really as expo will keep adding the extends to tsconfig so would always be at risk of being committed and causing this issue to reappear.

10

Tests commits have gone well and code is being reviewed correctly again using the extended config from node_modules.

11

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