SPFx Version

Copper Contributor

Hi everybody,


in our company we use SharePoint online and SPSSE onpremise. At the current state they support SPFx version 1.15.2 and 1.4.1. This causes some problems:


  1. Entire development process is unnecessarily complicated
    1. Each developer needs different node.js version or tricky workarounds (NVM Manager, multiple VMS, ...)
    2. Constantly switching react/typescript version
    3. Code quality/audit/dependency checks are not possible on onpremise due it's very old framework version (2018)
  2. We can't use PnP libraries in it's glory (example: have to use old peoplepicker-control, workaround to run pnpjs, ...)
  3. We can't use most of the community webparts for on-premise (example: https://github.com/pnp/sp-dev-fx-webparts/tree/main/samples) or we have to use a old/buggy version
  4. The same technical requirement must be implemented differently, because controls didn't exists onpremise or working differently


For the reasons mentioned, we continue to develop server-side components for on-premises and do not use the SPFx framework at all (for on-premise). Developing with an old framework version (almost 5 years) is generally bad practice. We wouldn't do that with any other framework either.


Please consider making SPFX updates and provide a basic roadmap,

best regards


2 Replies

@Michael_Joehnke I will suggest below for the new feature/updates requests:

  1. Submit feedback on SharePoint feedback portal where other users can vote: SharePoint Feedback Portal 
  2. Provide suggestion / Ask question at: sp-dev-fx-webparts issues  

Please click Mark as Best Response & Like if my post helped you to solve your issue. This will help others to find the correct solution easily. It also closes the item. If the post was useful in other ways, please consider giving it Like.


The server was always behind in terms of the SPFX, and from my understanding will be (at least in the next couple of years). What you could do:

  1. make your server SPFX development in Docker container/VM so you don't have to switch versions
  2. make most of your development in SPO, and only if it's really needed for SPSE (so you're utilizing the latest tech), another option would be - to build external interfaces for SP SE (like SPA, web services), where you don't care about SPFX version.

At some point, I guess MS will release another service pack for SE, but probably it will be again older than SPO.