Building SharePoint Framework solutions over time: what's your strategy?

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. Following the semver versioning patters, 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 up 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?

Photo by rawpixel.com on Unsplash