Cannot find .scss module error – Enabling SASS integration with your SharePoint Framework code

When creating SharePoint framework webparts in Visual Studio code, out of the box integration with SASS files (.scss) does not work. You get errors which look like this (when you’re using ts-lint that is).

This also causes pain and angst when it comes to running CI / CD in Azure DevOps and the build breaks because npm test wont run – the enzyme rendering of the component wont work because it cannot find the scss file.

Natively, typescript does not understand scss as an import and you need to let it know that it’s ok to include.

You solve this problem in two steps:

  1. Create a declarations.d.ts file in the root of the project
  2. Add a reference into the tsconfig file to use the declarations file


// We need to tell TypeScript that when we write "import styles from './styles.scss' we mean to load a module (to look for a './styles.scss.d.ts').
   declare module "*.scss" {
   const content: { [className: string]: string };
   export = content;


//add the following
"include": [

and that’s all 🙂


Reducing SharePoint Framework Code Smells: 4 – Configuring Sonar Scanner to test only our code

This is a series on how to set up SonarQube as a Quality Gate in your SharePoint Framework development process. The end goal is to add SonarQube to your build and release process through DevOps. These articles will explain:

  1. How to set up a sample SonarQube server in Azure
  2. Setting up a unit test sample locally
  3. How to set up sonar-scanner and connect it to SonarQube
  4. Configuring Sonar Scanner to test only our code


In the previous article we saw how to set up a sonar scanner locally and run a scan of our out of the box sample project. The code was a little smelly and there were some bugs found. In this article we are going to look at where those bugs come from and why they are not relevent to our solution. By the end we will have a working Sonar Scanner correctly scanning our code and running tests.

Looking at the bugs and smells

Part of the reason why I left this in here was to see some of the beauty of SonarQube and the information it provides us. How does it know there are bugs? What smells?

Looking at our report closer we can click on the project and then the Bugs and we see the following bugs.

There are a couple of important things to note here:

  1. The bugs are coming from the JEST folder
  2. It checked .css as well as .js

Clicking on the See Rule we can see why it decided this was a bug.

SonarQube runs off pre-built rules (like a linter does) and determines that the quality of the code is a “bug” because it breaks a rule. This is really interesting and drives us to create better code – which is ultimately to goal of using the capability!

looking at the bug shows you where in the code – pretty cool eh?

You can poke around with the code fails as well, that’s not why we are here – but it is fun to look around.

These two files are in the JEST folder which is not “our” code and therefore there is no need to test it. So let’s configure the scanner to look at “our” code.

Configuring sonar scanner via CLI

If you are running sonar-scanner locally you can change the file to add some of the default values. In this case we are going to coninue to pass the parmeters in through the CLI because we are not going to be able to do that when we go to the CI/CD pipeline in Azure DevOps.

We are adding new parameters

  1. updating sonar.sources to point to our code
  2. adding sonar.typescript.lcov.reportPaths so that SonarQube can use the coerage reports created by Jest
  3. adding sonar.tests so that we are specific as to where our test are located
  4. adding sonar.exclusions so that we are not assessed for coverage on our tests, which would be silly
  5. adding sonar.test.inclusions to identify which files are our “tests”
  • sonar-scanner.bat

Running the sonar-scanner.bat command again we get some slightly different results this time……

MUCH better 🙂

Loking at the code coverage section we can see that there are some additional files which have been added that are not really what I wanted to test.

What isn’t covered?

Looking into the files which failed is really helpful because you can visually see where the lines with no coverage are !!


In this article we have see how to configure sonar scanner to scan our files and not the dependancies. In the next article we will see how to connect to SonarQube from Azure DevOps



Reducing SharePoint Framework Code Smells: 3 – Setting up Sonar Scanner and connecting to SonarQube

This is a series on how to set up SonarQube as a Quality Gate in your SharePoint Framework development process. The end goal is to add SonarQube to your build and release process through DevOps. These articles will explain:

  1. How to set up a sample SonarQube server in Azure
  2. Setting up a unit test sample locally
  3. Setting up Sonar Scanner and connecting to SonarQube
  4. How to run a sonar-scanner review manually
  5. How to integrate the code review into your Azure DevOps build and release process.


In the previous article we saw how to clone and load up the PnP react-jest-testing sample and run an initial test. I am not going to go into the advantages of unit testing your code – but if you want more information on how and why check out these excellent MVPs and their blog posts on the subject.

In this article we are going to set up Sonar Scanner to analyze the code locally and then connect it to our SonarQube server.

Setting up Sonar Scanner

Sonar Scanner can be downloaded and installed from here. You have to extract it and add the bin directory path to your environmental variable (way easier in Windows 10) to get it to work.

Once that is up and running there are a number of steps which we have to go through to turn our npm test into something which will create reportable files for SonarQube. The process of testing is the same, the only difference is the output and how it is handled.

Setting up a SonarQube Project Key

Within our SonaarQube server create a new project – in this case I called it IceCreamShop for the sake of simplicity

From that I get a the ability to generate a project key

and from there we can continue and get instructions on how to run the sonar scanner for this project.

The information at the bottom is the important part for us:

  • sonar-scanner.bat -D”sonar.projectKey=IceCreamShop” -D”sonar.sources=.” -D”” -D”sonar.login=dba68d82c931efe82e8692c9a25bc7c31736b286″

Put another way this is running the CLI for sonar-scanner and passing variables which are not directly configured in the sonar scanner properties config file (which we will come to later)

  • sonar-scanner.bat
    -D”sonar.projectKey=IceCreamShop” #projectKey
    -D”sonar.sources=.” #run the scan from the root directory
    -D”” #SonarQube server for the results to be posted to
    -D”sonar.login=dba68d82c931efe82e8692c9a25bc7c31736b286″ #the project key to associate the scan with

So let’s go ahead and run that in our project and see what happens…….

— NOTE —

On a windows machine you must run visual studio code as adminstrator – otherwise it may not be able to create and delete folders as part of the test running process.

If you see an error around – INFO: Sensor SonarCSS Rules [cssfamily] – you must have the sonarJS plugin 5.2.1 installed.

The result is not pretty – for many reasons but let’s look at what we have for now, for this article. As you can see from the output below there are a number of errors and issues reported.

If we look at our SonarQube server though we can see an analyzed project.


Looks like we have some smelly code, some bugs and some code debt – this is a really nice feature of SonarQube and why it is helpful in Code Quality reviews. We dont have any code coverage though which is odd……..

As we will come to see in the next article. The code is not all that smelly, it is actually our configuration. 🙂





Reducing SharePoint Framework Code Smells: 2 – Setting up a sample for unit testing

This is a series on how to set up SonarQube as a Quality Gate in your SharePoint Framework development process. The end goal is to add SonarQube to your build and release process through DevOps. These articles will explain:

  1. How to set up a sample SonarQube server in Azure
  2. Setting up a unit test sample locally
  3. How to run a sonar-scanner review manually
  4. How to integrate the code review into your Azure DevOps build and release process.

It is apparently going to take more blog posts than I expected. But I like to spread these things out – easier to maintain and easier to find what people are looking for.


In the previous article we saw how to create a sample SonarQube server in Azure. In this article we will look at how to manually run a SonarQube scan linked to the server we created. The results might be smelly.

In this example we are going to use the SharePoint PnP example for creating unit test with React in SFPx

Setting up the repository locally

Create a new folder for the repo locally and then clone the repository through the terminal with “git clone”. We have to take the whole repo but are not going to use the whole of it – just the react unit testing section.

Then once that is complete navigate the ./samples/react-jest-testing folder

run an npm install and we are ready to go.

Initial npm test

Immediately after the install you can run and npm test and see how the sample code hang up under testing. You will get one intentional fail and some code which is not convered by tests. This is to be expected.

The reason we add unit tests to a project is ultimately to improve the quality of the code. This leads to reduction in maintenance costs, lifts the confidence of the development team and allows for continuous integration builds to identify where breaking code has been introduced into a build process within a team.

This project is a great place to start to learn how to unit test within React and the SharePoint Framework.

What we want to be able to do ultimately is collect all of this information on the SonarQube server. We will get to that 🙂

In the next article we will look at sonar scanner and how we hook that up to the SonarQube server.








Fixing SPFx node-sass binding error on ADO release pipeline

When trying to run the gulp upload-to-sharepoint  encountered the following issue when creating a release pipeline for an SPFx web-part. There was a problem with no binding available for node-sass

[command]C:\NPM\Modules\gulp.cmd upload-to-sharepoint –gulpfile D:\a\r1\a\build\release\gulpfile.js –ship –username *** –password *** –tenant mckinseyandcompany –cdnsite sites/apps/ –cdnlib ClientSideAssets
2019-06-12T14:51:53.5954467Z [14:51:53] Working directory changed to D:\a\r1\a\build\release
2019-06-12T14:51:54.5490645Z D:\a\r1\a\build\release\node_modules\node-sass\lib\binding.js:15
2019-06-12T14:51:54.5497252Z throw new Error(errors.missingBinary());
2019-06-12T14:51:54.5498022Z ^
2019-06-12T14:51:54.5499258Z Error: Missing binding D:\a\r1\a\build\release\node_modules\node-sass\vendor\win32-x64-48\binding.node
2019-06-12T14:51:54.5499538Z Node Sass could not find a binding for your current environment: Windows 64-bit with Node.js 6.x
2019-06-12T14:51:54.5499883Z Found bindings for the following environments:
2019-06-12T14:51:54.5500034Z – Windows 64-bit with Node.js 8.x

and the error was actually staring us in the face – “binding available for Node 8″……..

The solution, just like for the build process, you have to add an agent task to ensure the correct version of node is used for the release process.

Using npm ci as part of the SPFx CI CD process through Azure Dev Ops

During the Automated Build and Deploy process for a SharePoint Framework Web Part (as documented here) one of the steps you go through to install the application on the build server is a familiar step ‘npm install’.

This works just fine when working locally and should be, but it is inefficient as part of an automated build process.

For a good explaination of why, check out this stackoverflow answer

npm install reads package.json to create a list of dependencies and uses package-lock.json to inform which versions of these dependencies to install. If a dependency is not in package-lock.json it will be added by npm install.

npm ci (named after Continuous Integration) installs dependencies directly from package-lock.json and uses package.json only to validate that there are no mismatched versions. If any dependencies are missing or have incompatible versions, it will throw an error.

In my experience this can speed up the build process by more than 50% and as the npm install is the rate determining step for the overall buil, this is very helpful.

The step in the process for the build should look like this:

I have submitted a pull request to update the documentation and we will see if it is worthy 🙂



Correcting SPFx gulp –ship Uglify Errors: Unexpected token: punc (()

We came across the following problem when trying to execute a gulp --ship on out SPFx development

[15:03:34] Starting subtask 'webpack'...
[15:03:49] Error - [webpack] 'dist':
list-view-demo-webpart-web-part.js from UglifyJs
Unexpected token: punc (() [list-view-demo-webpart-web-part.js:962,7]

In researching this issue it turns out that this issue stems from a problem with the webpack uglify plugin (uglify-webpack-plugin) which historically does not work with ES6 code.

From what I read, it seems like the current SPFx 1.8 does use the correct version of webpack and the uglify plugin to avoid this issue but it was still coming up.

We solved the issue by implementing a suggestion to a related issue on github

The key was presented in one of the responses to the issue

By replacing the uglify plugin with the terser plugin for webpack, the issue was resolved and we were able to Build and deploy.