SharePoint Framework offers you a pretty solid project setup, but on the other hand, it doesn’t give you options to optimise the gulp, build or the webpack configuration.
The more web parts exist in a single project, the slower the build task become and all the code in the project will be compiled at once, instead of smaller incremental builds. Technical possible but not yet supported.
The good thing is that there are some options you can directly trigger from your web part code. Some of these options affect webpack others can be applied in ReactJS. Not only in case of build times but also case of user experience and web part performance.
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.
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.
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.
When you are working with SPFX and you start it with gulp serve, it takes some time to start. During this startup many things happen but there are not clear indication if SPFx is working or what it actually does.
gulp server – default start
Once the workbench was started you see all the gulp task that will be executed with or without error and what it actually does.
The background tasks are well hidden, but you can take a peek into those background activities. It’s just a simple trick, but I use it every time now when I work with SPFX now.
Instead, execute gulp server and add the command line option --verbose. Execute SPFx with:
gulp serve --verbose
Now the hidden world and architecture of SPFX will become more visible. In additon you get sometimes many additonal informations what might goes wrong.
gulp serv – with verbose logging
From my point of view, it is easier and helps with debugging.
I will also see if the issue is caused by your configuration, code or locate a problem with SPFX.
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.
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.
Last June all default yeoman webapp generator got a new web server component named browsersync.io.
While the web server component of those generators used components such as connect, ‘gulp-webserver’ and ‘live reload’. Browser-sync overs similar and maybe better development support at once. Making configuration and integration easier.
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.