Is SPFx abandonware?

[smolattack]

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:

1. 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.

2. 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...).

[ghost]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[devsheeran]

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? Thanks

[smolattack]

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]

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]

I've been an SPFx developer since 2017, but now I'm encountering more and more problems with the SPFx:

• I cannot use packages that rely on React 18+
• I cannot use packages that rely on Typescript 5+
• We had to build complex workaround in our Azure DevOps pipelines so the critical vulnerabilities of the DevDependencies are not reported

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]

@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]

The time is coming to consider switching away from SPFx.

@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]

SharePoint Framework 2.21 supports Node.js v. 22 and TypeScript 5. This is great new. Thank you SPFx team :-)

[smolattack]

SharePoint Framework 2.21 supports Node.js v. 22 and TypeScript 5. This is great new. Thank you SPFx team :-)

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]

SharePoint Framework 2.21 supports Node.js v. 22 and TypeScript 5. This is great new. Thank you SPFx team :-)

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

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.

[Amey-MSFT]

Hello @smolattack, Thank you for bringing this issue to our attention. Could you please confirm if the issue still persists for you?

[Amey-MSFT]

We are closing this issue for now. If the problem persists, feel free to reopen it or open a new one.

[lucmoco]

I don't agree with closing this issue. This shows a lack of understanding of the SPFx user's needs and of the obsolescence of the SPFx dev stack. The problem is still relevant, the latest version (1.21.1) uses the following:

• React 17 (the current version is 19, and more and more NuGet packages do not support v. 17 anymore)
• TypeScript 5.3 (the latest version is 5.8)
• There are still a lot of messages about vulnerabilities (including critical ones) that are output when installing the npm packages.

[smolattack]

I don't agree with closing this issue. This shows a lack of understanding of the SPFx user's needs and of the obsolescence of the SPFx dev stack. The problem is still relevant, the latest version (1.21.1) uses the following:

* React 17 (the current version is 19, and more and more NuGet packages do not support v. 17 anymore)

* TypeScript 5.3 (the latest version is 5.8)

* There are still a lot of messages about vulnerabilities (including critical ones) that are output when installing the npm packages.

They are just too big to care. They just keep screwing around with Adaptive Card Extensions which no one is asking for.

[Amey-MSFT]

Hello @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]

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]

@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]

@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:

• stealing high-privilege connection tokens in a CI/CD pipeline
• injecting malicious code into the final bundle
• executing malicious code on the developer's machine

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]

I completely agree with @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.