When I looked at the repository of my SimpleStyle Guide, I couldn’t believe that it was almost two years ago when I started this side project. Which those two years this Style Guide helped me in many projects to document all the changes in classic as well on the modern experience in SharePoint and Office 365.
The first version was only planned to give people a more comfortable use for theming tokens in SPFx projects. Today I released a new version that improves the typography in a way that Office UI Fabric currently not provides.
This new release is mainly targeted for accessibility and gives the ability to define custom classes based on the outlined typography.
A while back I wrote about on how to use the theme slots in the SPFx projects through SASS. It allows you to write web parts that reflect the default theme colours of a site. Instead, using fixed colour values, you can use variables in the CSS code of your artefacts.
To make the overall process faster I recently released and NPM packages including all the SASS colours plus some extras.
I believe one on the most used front end tools in the web development world is out there is Moustache or Handlebars. It is easy to use; you can write native HTML and compelling too.
In the SharePoint world, many web parts directly show data on the page, and therefore this is the right weapon of choice to get fast going.
Right after the first version of SPFx become public available, I created a ticket in GitHub on how to use this front end tool. With the RC0 drop of the framework, a new functionality has become available that allows you to embed Handlebars through a so-called webpack loader. I was pretty excited when Pat Miller tweeted me about this.
— Pat Miller (@PatMill_MSFT) January 13, 2017
Let me show and explain what steps are required to make use of it in your next project.
Now the SharePoint Framework has become general available I expect that it requires only to update only the npm packages mostly. A simple upgrade of the installed packages will be enough in future. During the beta phase you add to do manual step in addition to upgrade your project to the latest drop.
With every new drop of the SharePoint Framework it seems that always the same procedure needs to be executed to update existing projects.
npm is capable of scripting. To be able to execute a script, it needs to be added to the ‘package.json’ file.
Open the ‘package.json’ and look out for the script section. To register the update script create a new entry “update-spfx” and chain all commands delimited by ampersand together.
"build": "gulp bundle",
"clean": "gulp nuke",
"test": "gulp test",
*** Update 21.09.2016 for Drop 4 of SPFX use the following update-spfx command ***
"update-spfx": "npm install @microsoft/sp-client-base@latest @microsoft/sp-client-preview@latest --save & npm install @microsoft/sp-build-web@latest @microsoft/sp-module-interfaces@latest @microsoft/sp-webpart-workbench@latest --save-dev & npm prune & npm dedupe & gulp nuke & gulp"
Now you are ready to execute the following command
npm run update-spfx
After all the steps have been finished, you are ready to go with your new drop of the new SharePoint Framework.
If you think it feels like hacking. Well, it is the normal way to handle such things in NodeJS.
For the next drop or a version of the SharePoint framework you just need to execute the script again. In case something have changed please check out the documentation or simply modify the update script to the changed requirements.
How it works
Like mentioned before you can chain all the commands together. The first part contains
npm update. After the update you can specify all the node modules you like to update. You can simply add all packages right after the update and don’t need to update them individually.
You also don’t need to fumble around with the package versions the
npm update command does this for you.
I this case we had three packages to update.
Right after the package name you see and additional @-sign. This defines to which version you like to update. ‘@latest’ indicates the latest version which actually is the version of the current drop. Luckily, there is only latest version with every new drop.
The next commands that needs to be executed are
npm prune, followed by
npm dedupe, followed by
gulp nuke, followed by
In case you like to make sure you really rebuild your project can use
gulp build. This will explicitly call a rebuild. The next update can come and you only need to execute
npm run update-spfx again. Before you execute you should definitely check if something might have been changed.
In this case you can add or modify the commands.
Final hint – npm rebuild
The new SharePoint Framework contains a lot of binary components. Those components needs to be rebuilt / recompiled on your client first.
Sadly rebuild only happens when you install a package, but not during an update. The additional command that needs to be executed in this case is.
Optionally you can change this command to your
npm update script too. In this case make sure that all those components are freshly built. Eve if not required it won’t hurt your installation.
This was actually the first question I asked after the new framework has been released. Since then there has been an ongoing discussion on that issue.
When you created a new project using a yeoman generator you’d expect a proper gulp/grunt/whatsoever file that list all the task required to build and develop the project.
When you open the gulp file of the new SharePoint Framework you see just the following lines of code.
const gulp = require('gulp'),
build = require('@microsoft/sp-build-web');
The rest of the SharePoint framework is well hidden and deeply nested inside the
node_modules folders. Theoretically, you can whatever you like in this folder, but your changes will get lost whenever fresh version will be checkout out form the source control and/or
npm install will be exited, upgrade your project to the newest drop of the SharePoint Framework or install an updated version of any package. The
node_modules folder is the
_layouts folder of the new SharePoint Framework but you can be sure that files in there will be always replaced.
My mate Waldek wrote a great blog post on how to extend the SharePoint Framework with a custom build task.
I think his article is suitable for a deep integration in the SharePoint Framework. From my point of view, it solves a problem that exists because of the Framework.
I working with yeoman generators for more than two years now and I’ve never seen a gulp implementation that only contains of a simple function call. The new SharePoint Framework follows in this case a pretty uncommon approach. I was clueless for a while.
In SPFX everything is built on gulp and it turn’s out that adding a custom gulp task is much simpler than I have expected. However, sometimes it is hard to see the forest for the trees.
Let me explain how to accomplish the same thing Waldek describe just by standard gulp methods but first let me explain some basics.
You might have heard the Unix Bash Shell is now coming to Windows. To be more specific a whole Linux sub system based on the Ubuntu distribution comes to Windows. This addition to Windows was announce at this years Build Conference and I knew exactly how this would match to my clients and other people in the SharePoint Community. Especially with the new SharePoint Framework you should know this option because it makes many things easier using NodeJS on Windows.
Last week I played a little bit with node.js, gulp and Office UI Fabric. When I tried to install this UI Framework through bower.io i wanted to inject this bower components directly into my source code via gulp-wiredep. Sadly this failed because somehow the packages was broken. After a short research i found the reason for that and fixed it right in the framework on GitHub.