You start a new SharePoint Framework project. You use the latest version of the SharePoint Framework. But for how long will you be able to stay on the latest version?
Evergreen framework
Since its general availability over a year ago, we’ve seen a number of new versions of the SharePoint Framework. Through these regular updates, Microsoft shows us their commitments to make the SharePoint Framework the best SharePoint customization model ever. Each release contains new capabilities that introduce new scenarios. But as compelling as it is to always use the latest version of the SharePoint Framework available, how sustainable is it?
One version or two versions
SharePoint Framework solutions can be used both with SharePoint Online and SharePoint on-premises. SharePoint Online continuously receives the latest updates to the SharePoint Framework using its latest version available, and Following the semver versioning patterns, the major version updates we’ve seen so far were backwards compatible.
When building solutions for SharePoint on-premises, the situation looks a bit different. The version of the SharePoint Framework that you can use, is dictated by the patch level of the farm where the solution will be used. At the moment the choice is simple, as there is only one version of the SharePoint Framework supported on-premises. In the future however, when more versions are available, you will need to verify the patch level of the target farm or you will be in for an unpleasant surprise.
The price of using the latest
SharePoint Framework uses a toolchain with a complex dependency tree. This is partly related to how the SharePoint Framework toolchain is composed, but also partly inherent to using the Node-based dev stack. Updating one package, could trigger updates of many other packages which could turn out to be incompatible with other packages in your solution. As a result, you’d be left with a broken project. So unless you have a very good reason to update, I suspect, that most likely you will keep using the specific version of the SharePoint Framework you started with for as long as possible.
So what’s your strategy
So if this is the case, it will mean, that over time, you will have a number of projects each using a different version of the SharePoint Framework. To stay efficient you will need a way to quickly switch between the version of the SharePoint Framework required for the particular project. Globally installing the SharePoint Framework Yeoman generator is hardly an option. So what is your strategy? Will you be using local installs, nvm, Docker, VMs or something else altogether?
By using the SharePoint Framework, you are already following the best practices for building and securing customizations, but there is always an element of risk. Why not go one step further and use Rencore’s customization Risk Prevention solutions to secure your SharePoint today!
This blog post has been originally published on Waldek’s blog.
