Repository navigation
Is SPFx abandonware? #9463
Description
What type of issue is this?
Question
What SharePoint development model, framework, SDK or API is this about?
💥 SharePoint Framework
Target SharePoint environment
SharePoint Online
What browser(s) / client(s) have you tested
- 💥 Internet Explorer
- 💥 Microsoft Edge
- 💥 Google Chrome
- 💥 FireFox
- 💥 Safari
- mobile (iOS/iPadOS)
- mobile (Android)
- not applicable
- other (enter in the "Additional environment details" area below)
Additional environment details
No response
Issue description
The whole of the first page is just issues that haven't even been triaged. Running on old versions of Node, TypeScript and React. Does not work with the latest Graph toolkit.
My clients keep asking me to write SPFx apps for them as they think that the framework is fully supported. I, as a developer, can see that this is abandonware and should not be used for greenfield projects and existing solutions should be transitioned to something else.
Please provide guidance on an official doc page for business users advising them that SPFx is not suitable for production. Alternatively, provide guidance for developers on how to handle:
-
Issues with outdated packages (e.g., use of volta to switch between node version, how to check what version of React or TypeScript your dependencies require, if you have build errors). In your docs, you mention that only Node v18 is supported but no practical guidance on how to switch between versions. It is not explicitly stated that a developer is not able to just update everything themselves. You don't mention anything about old TypeScript or React versions and that they can not be updated and that effort has to be made to seek older versions of your desired dependencies. Even with the proposed update to TS 4.9 that didn't happen, I still wouldn't be able to use TanStack Router.
-
How to explain the embarrassing number of npm/pnpm warnings during the build process. I sometimes have to hand over my code to a client who wants to build the solutions themselves (via CI/CD) and so I'm stuck having to come up with excuses. We need a docs page that gives the right assurances which can just be sent to our clients (SecOps, DevOps, architects, PMs, etc...).
Activity
devsheeran commentedon Feb 27, 2024
You and your client can take comfort in this important message from the Microsoft documentation - "You can safely ignore these log warnings & error messages" :/
Seriously though, React 19 is coming out soon and it will do away with unwieldy hooks like
useMemo, and we are still on React 17.0.1 (released 2020 October 22 - about 3.5 years ago at time of writing). Will SPFx be updated more frequently and support React 19 anytime in the next year or so (or ever?), or is this basically on life support as per OP title? Thankssmolattack commentedon Feb 27, 2024
The whole of React is unwieldy and I'd rather use Solidjs. Unpopular opinion? Sure, but that shouldn't stop me from using it in SPFx (wasn't that the whole point of this framework?).
That important note is good (for a chuckle).
edelms commentedon Apr 21, 2024
We've used SolidJS in some of our SPFx projects already.
Does not solve the issue of outdated libraries in general, but gives a great performance and DX.
If you want to give it a try, I have written some how-tos (currently for solid and tailwind).
https://edelms.github.io/spfx-x
lucmoco commentedon Feb 18, 2025
I've been an SPFx developer since 2017, but now I'm encountering more and more problems with the SPFx:
Numerous issues are created in the SPFx team but there are no answers or other follow-up.
The time is coming to consider switching away from SPFx.
lafe commentedon Feb 21, 2025
Luc Mo Costabella (@lucmoco) You can also add Fluent UI 9 to that list. Fluent UI 9 "merges" the Teams UI Framework and the existing Fluent UI 8 version and is a MAJOR breaking change if you come from Fluent UI 8 (aka major rewrite of all components that use Fluent UI 8). The default for SPFx is still Fluent UI 8, so SPFx encourages you to write new UI components with a UI framework that is, for all intents and purposes, deprecated at this point.
smolattack commentedon Mar 24, 2025
Luc Mo Costabella (@lucmoco) If this was ever a course of action that a developer could take, I'd have done it years ago. Luckily for Microsoft, technical decisions are made by technically illiterate directors in the real world.
These days I work a lot more with Power*shit products so there is no mode in which Microsoft loses business.
lucmoco commentedon May 1, 2025
SharePoint Framework 2.21 supports Node.js v. 22 and TypeScript 5. This is great new. Thank you SPFx team :-)
smolattack commentedon May 5, 2025
The version of TypeScript they now support is 5.3.3 which was released in 2023. Still an obstacle if you want to use any recently updated open source projects
lucmoco commentedon May 6, 2025
Sure, but it's already a step forward. For me, it allows me to use the most recent version of some packages that rely on the TS 5 Syntax and would not compile with SPFx 1.20.
6 remaining items
Amey-MSFT commentedon Jul 17, 2025
Hello Luc Mo Costabella (@lucmoco), smolattack
We apologize for any inconvenience this may have caused.
We will coordinate with the engineering team to clarify these points and will provide you with an update as soon as we have additional information.
Thank you for your understanding.
VesaJuvonen commentedon Aug 12, 2025
Thanks everyone for pushing here to keep Microsoft honest and transparent on the supportability and roadmap of the SharePoint Framework. We are committed on supporting SharePoint Framework (SPFx) also in future as the extensibility model for Microsoft 365, including SharePoint.
Externally used SharePoint Framework technical stack is dependent on the technical stack used by SharePoint Online. This is specifically the case with React as the same React bundle will be automatically used by the 1st party (out of the box) and 3rd party (custom developed) features. Due to this historical dependency, we cannot unfortunately provide updated technical stack for 3rd party until the SharePoint Online stack is updated - which is for sure frustrating for us as well as we want to provide best possible technical platform for the ecosystem, given the limitations we have.
There's luckily some signs on the progress here. Internally we are in progress on moving to React 18 and as we have shared in the public community calls, we are looking into having React 18 support with the SPFx 1.22 (current plan - hopefully will happen). This updated dependent on the underlaying services and that they are upgraded, but we are crossing the fingers to be able to provide and confirmed update for this soon. Similar story with the newer TypeScript versions.
On the vulnerabilities - these are closely followed by our engineering team and any runtime critical issue is absolutely addressed in fast manner. There developer time experience (with localhost) has been previously considered as non-critical area as there's no attacking vectors to the localhost running Node server - where the vulnerabilities are flagged. These are however presented in unclear manner and we have made a decision to address these within upcoming semester to avoid any confusion on the developer environment (localhost) vs production environment vulnerabilities with SPFx.
Thank you for keeping on pushing things getting addressed. Team is working for the fixes with the given limitations they have and we highly appreciate your passion to keep this platform evolving. Thanks for the input - more details immediately when we have confirmed updates.
smolattack commentedon Aug 15, 2025
Vesa Juvonen (@VesaJuvonen), Just let us use our own tech stack. Make it optional and make it clear that your bundle will be bigger. Why are are not considering this? Plenty of professionals in the community have demonstrated how this can work.
lucmoco commentedon Aug 20, 2025
Vesa Juvonen (@VesaJuvonen), thanks for taking time to give us some insights about the SPFx roadmap.
About the devDependencies, which have many vulnerabilities, I think these must be taken seriously. They are not only used at devtime, and also not only on localhost. They are used to build the package, and if they are compromised this can pose security risks such as:
Also, when using tools such as GitHub Advanced Security for Azure DevOps code analysis, a lot of critical and serious vulnerabilities are being reported, and they hide eventual vulnerabilities that affect runtime packages.
Typescript is only a build-time dependency, so the version used should not be affected by the SharePoint 1st-party code. The current architecture based on a big rush-stack-compiler package with many dependencies (including a version of TypeScript) seems very inflexible and could be relaxed.
LastGunslinger commentedon Aug 20, 2025
I completely agree with Luc Mo Costabella (@lucmoco) and smolattack on this. If Microsoft is serious about SPFx being a valid path forward for developers, there needs to be serious thought put into decoupling it from the SharePoint Online stack. My team has been using React 18 in our own SPFx applications for nearly a year at this point with no ill effects besides a larger bundle size, which is greatly offset by the additional features that our devs are able to deliver to users. I know that whenever I talk to other SPFx developers, the number one thing that they all want is either a faster schedule for updating dependencies, or the ability to use our own build dependencies if we know how.
React 18 is over 3 years old and has already reached EOL at this point, and there has been absolutely nothing from Microsoft about the possibility of adopting 19 for SPFx. Microsoft's security teams may be alright with so many of their dependencies being out of date and/or raising security issues, but many organizations do not see it that way.
VesaJuvonen commentedon Nov 1, 2026
React 18 with Node.js 26 was delivered as part of the 1.24 release - with the new Copilot UX components.
Thank you for your passion and input on these topic. We are committed to continue evolving SPFx - and have more frequent updates planned in future. Closing this for ow - as the 18 is delivered. Yes - way way way overdue - but delivered finally.