During last weekend I already teased a web part named ‘Panthema’. I was a bit surprised by the interest in this helpful tool for developer, consultant and everyone who has to manage themes in SharePoint on Office 365. I also think it helps a lot in debugging the colours used.
Recently many new user interface element got introduced to SharePoint that provides additional information about other services in Office 365. While you can argue this information might be valuable for users, you can also say that that information is just a consumer marketing attempt for already paid products.
In general, to keep the user informed it is a great thing to have a feature like this but from a design perspective and even end-user experience, those elements are not optimal. If this kind of information is valuable for the user inside an organisation, it is up to the organisation and not a decision made by any service provider.
To be clear, if this shows up on a free OneDrive user interface, but it is not something for a corporate environment.
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.
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.
Sometimes there is the requirement to move files from your source code directory to the lib folder. These files can be images, JSON files or any imaginable asset that is not recognised by the build chain of SPFx.
There are two ways to achieve this one. One used gulp the other gets accomplished through the configuration of a
copy-static-assets.json. Let me explain these to methods what scenarios suites best in which case.