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.
I know the Feedback and Mobile App buttons are essential for Microsoft, but many of my customers ask me to remove it. There a mainly three reasons for that. The first is the location and loading behaviour of those buttons. It takes a while until those buttons are loaded and catch a lot of attention of the user once they are visible on the page.
The second reason is that the location sticky on the bottom of the page might not be the perfect spot for those buttons. I might be more useful to have them somewhere in the header or suite bar.
I planned to write a blog post how to run the SharePoint Framework Workbench in a Docker container on Azure. After I found out this is currently not possible I switched the scope of my trial. Instead, I tried to create Docker container dynamically for projects based on SPFx.
There are two key takeaways explained in this post. You will learn how to build your Docker file specific for your upcoming projects, and you get to know how you can demo and try out all SPFx Pattern and Practices samples regardless the version currently needed by those projects.
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.