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.
Like I promised yesterday. You can even run a specific SPFx generator version with a specific NodeJS version through the help of NPM.
While it might not is a practical approach it can help you sometimes when you like to run for example an older version of the project to test some behaviour before you fix the issues.
Have you ever wanted to run an older version of the SPFx generator? Maybe on an existing project to add some new assets? It is possible without any installation of the generator at all. Recently a tool was released inside your NPM installation that is named ‘NPX‘.
In short, NPX is a tool that allows you to run npm binaries and packages without having them installed locally. This tool got first released in NPM 5.2.0.
Whenever you save a TypeScript file in your SPFx project, the build chain creates a new build and refreshes the local workbench automatically.
There are some situations you like to have this support for other asset or frameworks too. In most cases with the PnP/SPFx generator, we need to force a build when a Handlebar or VueJS file get saved.
So the goal is to hijack the build process and add some custom file watch based on the requirement of the framework or file. Why file? Imagine you have an SVG file in your solution. The expected outcome is that you see the changes immediately in your browser.
The key word to this is watch. It requires a custom file extension watch that than trigger the build.
Right before the launch of the first version of PnP/SPFx I had a longer chat with a friend of mine Thomas Goelles, and he pointed out that it is great to be able to re-run the generator to add more web parts using a specific version of a framework. There was one fact that we haven’t thought about or maybe overlooked. What happens when the current project setup does not support the required version yet?
The previous version had merely a blocking mechanism implemented that checked if the current project was created using version 1.6.