I've been developing a library of SPFX components (to date, SharePoint web parts) for our corporate intranet SharePoint site - and I'm going to share a few tips.
 |
| Two of my web parts, running in a page on my developer tenant |
First - join the Microsoft 365 Developer Program. This is free, and gives you your own Office 365 "developer" tenant, allowing you to test deploying to your own private app catalog, and to play around with creating and maintaining SharePoint pages. The restriction is that you should only use the tenant for development/learning purposes (perhaps obviously, not for production use). Also, your developer tenant has a limited life of 90 days. Good news, is that if you're using it - it will renew automatically.
Second - how do you manage the updating of sppkg package files in the app catalog?
Example scenario, I deployed an FAQ web part, and realised I wanted to make some improvements to it. I uploaded the revised version of the .sppkg file to the app catalog, and could see it had been registered.
However, it was very hit and miss as to whether the old or new version was delivered in the front-end of SharePoint.
I found that there are three version numbers that you need to update in the solution config files:
config/package-solution.json
In this file, there are two "version" fields which you should increment (both to the same value)
package.json
At the top of this file, there is another version number. I understand best practice suggests that this field should be set to the first three digits of the version number in config/package-solution.json.
As an example, if you have the "version" field in config/package-solution.json set to 1.2.3.4, you should have the "version" field in package.json set to 1.2.3.
My belief (maybe wrong!) is that it's the version number in package.json which is used to form the unique (or, cache busting) Url for the client side assets.
Does this mean that you shouldn't change/use the last digit of the version number in package-solution.json? If you're using the first three digits of that version number in package.json, then yes - I think you should ignore the last digit in package-solution.json. This is what I'm doing personally. I've not noticed any problems with updated packages not being deployed in the front-end.
If I'd been testing all this in production, relying on our IT team to deploy the sppkg files for me - it would have taken forever to work out. This is where having your own personal developer tenant is so, so useful.
More tips to come...
Comments
Post a Comment