When you like to version your SPFx solutions correctly, then it is not enough to upgrade only the ‘package-solution.json’ in the config folder. You might also want to upgrade the ‘package.json’ file with a corresponding version number too.
Many projects that use gulp as the build system mostly implement a particular gulp task that is name ‘dist’ for distribution. This task package and bundle everything for production use.
Can we have a gulp task like this in SPFx too? Yes, we can have this too. First, let us take a look at the steps you need to do when you like to create a clean ‘sppkg’ file in the SharePoint Framework.
Without a doubt, the SharePoint Framework is one of the most successful adoptions and customisation models that has ever found its way into SharePoint, and there are reasons for this.
Over the past years, I talked and worked together with many developers that haven’t ever touched SharePoint before or found its way into this Application.
Many of those had a background in C# while, especially for a branding project, was more living in the web world. The overall feedback was that it is this kind of development unique in many ways.
Today I published the first beta version of the upcoming PnP/SFPx version 1.6.0. It is the most significant releases since the launch of the Angular Elements support for SPFx.
Instead of adding new frameworks at the moment this release focuses more on your development workflow. There are updates included that helps you to write cleaner code, reduce bundle sizes and last but not least helps you on testing your ReactJS projects.
When you write a new web part with the SharePoint Framework you might create a genius web part, where all the business logic is compiled into your web part. This approach makes sense when the web part is an isolated piece of work.
Sometimes you like to write pretty simple web parts that only access a backend or third-party API from somewhere on the Interweb. In this case, you can write all the data access inside your web part. Give the user the option to store APP Key, APP Secret and particular access token directly in the web part. Might pre-populate some of those properties of with your company-wide secrets and API keys too.
In case you recently upgrade NPM to Version 6.0 and created a new SharePoint Project through the Yeoman generator. There is a chance that you recognised the following new notification at the end of the NPM installation process.
What there are five vulnerabilities, one with severity low and four with severity high and I can run ‘npm audit’ to get a detailed report?
Don’t start to scream “fire” and run in panic through your office, uninstall all your SPFx projects from all your tenants, clean up your CDN, keep calm and learn the reason why this gets now reported after the installation.
You might have recognised that the workbench of the SharePoint Framework has a responsive design tester included. In this blog post, I take a look what possibilities we have to properly test the responsiveness and the user experience of a web part.
There are also some pitfalls included if you entirely rely on the integrated too.
The most straightforward example to make you familiar with how to create a custom SPFx Yeoman generator is to use Yarn instead of NPM as your default package manager. The approach to change the default package manager is simple, and many people already use it as there default package managing solution.
So, instead of adding the ‘–skip-install’ option whenever you start a new project just add this option to a generator.
The first step is, as always, to create a new NPM package.