SharePoint Framework

FIXED: SPFx HelloWorld build Errors preventing gulp build –ship: Browserslist: caniuse-lite is outdated

Marky Roden npm, SharePoint Framework, SPFx , , ,

I recently came across the following erring during a HelloWorld build process – this was preventing my build from being able to ship.

 

PS C:\REpo\SPFest2019-1> gulp bundle –ship
Build target: SHIP
[17:27:17] Using gulpfile C:\REpo\SPFest2019-1\gulpfile.js
[17:27:17] Starting gulp
[17:27:17] Starting ‘bundle’…
[17:27:17] Starting subtask ‘configure-sp-build-rig’…
[17:27:17] Finished subtask ‘configure-sp-build-rig’ after 80 ms
[17:27:17] Starting subtask ‘pre-copy’…
[17:27:18] Finished subtask ‘pre-copy’ after 98 ms
[17:27:18] Starting subtask ‘copy-static-assets’…
[17:27:18] Starting subtask ‘sass’…
[17:27:18] Finished subtask ‘copy-static-assets’ after 203 ms
Browserslist: caniuse-lite is outdated. Please run next command `npm update`
[17:27:18] Finished subtask ‘sass’ after 416 ms
[17:27:18] Starting subtask ‘tslint’…
[17:27:19] [tslint] tslint version: 5.12.1
[17:27:19] Starting subtask ‘tsc’…
[17:27:19] [tsc] typescript version: 2.9.2
[17:27:24] Finished subtask ‘tsc’ after 4.54 s
[17:27:24] Finished subtask ‘tslint’ after 6.5 s
[17:27:24] Starting subtask ‘post-copy’…
[17:27:24] Finished subtask ‘post-copy’ after 318 μs
[17:27:24] Starting subtask ‘collectLocalizedResources’…
[17:27:24] Finished subtask ‘collectLocalizedResources’ after 5.15 ms
[17:27:25] Starting subtask ‘configure-webpack’…
[17:27:26] Finished subtask ‘configure-webpack’ after 1.43 s
[17:27:30] Finished subtask ‘webpack’ after 3.78 s
[17:27:30] Starting subtask ‘configure-webpack-external-bundling’…
[17:27:30] Finished subtask ‘configure-webpack-external-bundling’ after 998 μs
[17:27:30] Finished subtask ‘copy-assets’ after 50 ms
[17:27:30] Starting subtask ‘write-manifests’…
[17:27:31] Finished subtask ‘write-manifests’ after 1.51 s
[17:27:31] Finished ‘bundle’ after 14 s
[17:27:32] ==================[ Finished ]==================
[17:27:32] Project sp-fest-2019-1 version:0.0.1
[17:27:32] Build tools version:3.9.26
[17:27:32] Node version:v8.11.4
[17:27:32] Total duration:19 s
The build failed because a task wrote output to stderr.

Solution

The solution is not immediately obvious – because the use of the caniuse-lite browserslist is not part of my package.json. It is buried somewhere deep inside of the SPFx code provided by Yeoman.

The solution sof npm update did not work.

After a little googleing the following solved the issue – and taught me about npm update 🙂

npm update –depth 10 caniuse-lite browserslist

PS C:\REpo\SPFest2019-1> npm update –depth 10 caniuse-lite browserslist
npm WARN @uifabric/utilities@6.45.1 requires a peer of @types/react-dom@>=16.3.0 <17.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN ajv-keywords@3.4.0 requires a peer of ajv@^6.9.1 but none is installed. You must install peer dependencies yourself.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.9 (node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.9: wanted {“os”:”darwin”,”arch”:”any”} (current: {“os”:”win32″,”arch”:”x64″})

+ browserslist@4.8.2
+ caniuse-lite@1.0.30001015
added 2 packages and updated 3 packages in 29.744s

and that solved the issue.

 

SharePoint Framework workbench port (5432), is the same as default PostgreSQL db listener (5432)

Marky Roden SharePoint Framework , ,

As we discovered by mistake, if you are one of those people lucky enough to work in multiple technologies, sometimes you can end up hurting yourself and spending far too long trying to figure out why.

It turns out that the default PostgreSQL database port is 5432 – the same as the SPFx workbench.

Installing PostgreSQL causes it to run automatically on computer start. So there is already something listening on port 5432 and your workbench appears to not work as you wanted it to 😦

Anyway you have a few choices to get your workbench to work:

 

 

Office 365 CLI change affecting SharePoint online Build and Deploy

Marky Roden SharePoint Framework ,

We saw this week that our build and deploy process for SharePoint Framework was breaking. We tracked it down to a change in the Office 365 CLI which was released recently.

Our previous step of logging into O365 so that we can deploy out package looked like this

#o365 spo login https://blahblah.sharepoint.com

The breaking change to the CLI was that they simplified the login process (makes sense)

https://github.com/pnp/office365-cli/issues/889

And now the command works without the spo precursor

#o365 login https://blahblah.sharepoint.com

 

 

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

Marky Roden SharePoint Framework, SPFx , , , ,

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

declarations.d.ts

// 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;
}

tsconfig.json

//add the following
"include": [
    "src/**/*.ts", 
    "declarations.d.ts"
  ],

and that’s all 🙂

Securing your AzureDevOps SharePoint tenant credentials with an Azure key Vault.

Marky Roden Azure Key Vault, AzureDevOps, SharePoint Framework , , ,

If you are following an automated Build and Release process for your SharePoint Framework then you will have come across the need to store your tenant SharePoint admin username and password as variables in the pipeline.

Whle this works and I believe the credentials are encrypted, this is not going to fly with enterprise corporate security. They are going to insist that the credentials are kept centrally in a secure KeyVault. Conveniently for us, a KeyVault is available for us to use in Azure.

Using the process described by the Azure DevOps Labs team you can set up a KeyVault and integrate it into your pipeline.

I am adding the KeyVault pipeline into an older version of an SPFx release (for the most up to date doc check this post out).

Once that is run the new password is successfully utilized instead of the variable I had stored within Azure DevOps.

 

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

Marky Roden AzureDevOps, SharePoint, SharePoint Framework, SPFx , ,

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 https://stackoverflow.com/questions/52499617/what-is-the-difference-between-npm-install-and-npm-ci/53325242#53325242

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 (()

Marky Roden O365, Office 365, SharePoint, SharePoint Framework, SPFx , , ,

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

https://github.com/SharePoint/sp-dev-docs/issues/2782

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

https://github.com/SharePoint/sp-dev-docs/issues/2782#issuecomment-475519680

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