SharePoint Framework (SPFx) is a page and web part model that supports client-side development for SharePoint 2016 (Feature Pack 2) onwards. It’s certainly a major milestone for Microsoft to let developers use their favorite frameworks and open-source tools, but if your solution is targeting SharePoint 2016, there are a few sacrifices you have to make, namely – downgrades.
If you try to scaffold and run the SharePoint Framework project with Yeoman SharePoint Generator without preparing your environment, you’ll run into this or similar error.
The reason is the version of node.js. For the time being (June 2020) SPFx only supports node.js 10.X.X for SharePoint 2019 or SharePoint Online and node.js 8.X.X for SharePoint 2016.
If you don’t want to alternate between different versions of node by reinstalling them, you should try nvm. It allows you to flawlessly switch between different versions of node.js without the need to download and install them manually.
Before you try to use any 3rd party libraries in your solution, you need to know that SharePoint 2016 doesn’t support the latest version of SPFx – it only comes with v1.1, which means lower versions of react.js and TypeScript. Some of the libraries of their parts will not be available without upgrading TypeScript, like the o-mighty PnPjs. Technically, the upgrade is possible, but more often than not it will interfere with other parts of your solutions.
What’s also worth noting is that SPFx for SP16 only supports development in the web part model and not extensions.
Below you can see all the default versions of node packages coming along with SPFx v1.1
Remember: to follow Microsoft’s convention, you should use @types for every 3rd party library and as you’re not using the latest TypeScript, you can’t trust npm with @latest. Instead, you need to pick an exact version of types for the version of the library that goes along TypeScript 2.4.
For the full compatibility, matrix refer to https://docs.microsoft.com/en-us/sharepoint/dev/spfx/compatibility
If you are on Windows, one of the most common problems is serving your solution to the workbench with a gulp.
The solution here is to set NODE_NO_HTTP2 environmental variable to 1 or, if you’re fine with it, serve the project without https by adding -–no-https flag.
