TeamsFx deprecation: What's the plan for SPFx WebParts in Teams?

[eppeque]

Problem

Our team relies heavily on the Teams Toolkit (now the Microsoft 365 Agents Toolkit extension for VS Code) to manage, build, and deploy SPFx Web Parts that run as personal apps in Microsoft Teams.

The recent update (v6.2.0) started the deprecation of TeamsFx tooling, with a complete removal planned for next year.

The issue is that TeamsFx allowed the use of very useful SPFx features in Teams like:

• Automating the Teams app manifest creation/updates.
• Simplified integration for things like Single Sign-On (SSO) which allowed the access to SharePoint lists. Apps data come from there so the access is crucial.

Key Concern

While SPFx itself is not going anywhere, the tool that made developing SPFx Web Parts in Teams easy is being removed. The new focus of the toolkit seems to be on AI Agents, leaving the core M365 development path for SPFx unclear.

We need to know what to do next.

Crucial Questions

We need immediate, clear guidance on the replacement strategy:

1. What's the replacement? Is there a new tool, SDK, or prescribed workflow for developing and packaging SPFx Web Parts specifically for Teams?
2. How do we maintain and migrate our existing SPFx Teams apps that depend on the TeamsFx structure and configuration?
3. Are we expected to return to a fully manual process (using just the SPFx Yeoman generator and then manually configuring the Teams manifest and deployment)? It's completely fine if the answer to this question is yes only if the %26loadSPFX%3Dtrue%26debugManifestsFile%3Dhttps%3A%2F%2Flocalhost%3A4321%2Ftemp%2Fbuild%2Fmanifests.js query continue to work after deprecation. It allows local development in the Teams UI to make UI/UX design easier.

Our existing SPFx apps are critical, and we need a documented path forward to ensure they continue to work.