What is meant by "Buildtime packages release is decoupled from the SPFx release"?

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

Additional environment details

browser version
SPFx version
Node.js version
etc

Issue description

With regards to the 1.19 beta release, could someone elaborate on the gibberish that is in the release notes?

What are buildtime packages as opposed to SPFx release and does this have any impact to us pleb developers? Can we use whatever version of TypeScript, React or Solidjs without hacks?

I don't think it's about any version of TS, React, etc.

If you check out the minimal 1.19-beta.0 package.json file, you will notice, that now not all @microsoft/* related packages have 1.19.0-beta.0 version (see image)

Looks like these "1.20.1" packages are "build time packages" and now their versions are decoupled from SPFx release versions.

Sergei Sergeev (@s-KaiNet)

But all of this stuff is proprietary and closed source. It is internal implementation of a black box that we can't control or do anything about. Bad product, bad DX, bad documentation, slow and poor support (e.g., extensions are still randomly failing to load half-a-decade later).

Obviously, not a dig at you Sergei Sergeev (@s-KaiNet). Your external library trick for on-prem solutions really helped me in a project I did a few years back. Wish we could do the same for SPO solutions as well or if Vesa Juvonen (@VesaJuvonen) did something about the dire state this product is in, instead of just adding features no one cares about (adaptive cards, etc... )

smolattack

smolattack - Flattered on the comment around the role I have, but there's a much bigger crew driving the features and priorities of the SPFx - my input matters, but so does your input, so thanks for your comments and feedback.

We have noted this feedback and have routed this back to the team for further discussion. Valuable comment and feedback on the requirements around more transparency and visibility on these kind of changes which can cause confusion.

Sergei Sergeev (@s-KaiNet) is correct around the direction with this. So the team responsible of the build time packages wants to break the release dependency with the other SPFx packages. This will mean more flexibility on the release cycles, but can cause also confusion as then we have multiple teams doing versioning in different sequence, so documentation and input is for sure needed.

There's still ongoing discussion on getting the SPFx Yeoman generator and packages open-sourced internally at Microsoft and there's lot of people who would like to do this. This would have though also significant impact on the normal build and publishing processes with resourcing impact, which is why leadership is a bit unhesitant to do this. Hopefully we can change this at some point, so that we can get more visibility on the packages and processes.

Hopefully that provides a bit more visibility on what's going on with some background information. Feedback is always welcome and incredibly important to get shared, so that we can route that to the people who make decisions behind the scenes. Thx 🙏

smolattack

smolattack - Flattered on the comment around the role I have, but there's a much bigger crew driving the features and priorities of the SPFx - my input matters, but so does your input, so thanks for your comments and feedback.

We have noted this feedback and have routed this back to the team for further discussion. Valuable comment and feedback on the requirements around more transparency and visibility on these kind of changes which can cause confusion.

Sergei Sergeev (@s-KaiNet) is correct around the direction with this. So the team responsible of the build time packages wants to break the release dependency with the other SPFx packages. This will mean more flexibility on the release cycles, but can cause also confusion as then we have multiple teams doing versioning in different sequence, so documentation and input is for sure needed.

There's still ongoing discussion on getting the SPFx Yeoman generator and packages open-sourced internally at Microsoft and there's lot of people who would like to do this. This would have though also significant impact on the normal build and publishing processes with resourcing impact, which is why leadership is a bit unhesitant to do this. Hopefully we can change this at some point, so that we can get more visibility on the packages and processes.

Hopefully that provides a bit more visibility on what's going on with some background information. Feedback is always welcome and incredibly important to get shared, so that we can route that to the people who make decisions behind the scenes. Thx 🙏

I simply don't understand what this new "feature" is. Sounds like some technical struggle you have internally which I don't see as a "feature". How does that help me as a developer?

Why are we on versions of TypeScript, React, Webpack that are OVER A YEAR OLD? Why don't you let us, as developers, choose whatever version we want? In most cases, I (or my clients) don't care about bundle sizes.

During the last few years, as the principal architect of large scale monorepository, I often get frustrated by the SPFX toolbox. The main issue is the lack of extensibility. The custom gulpfile is a joke, and the actual config objects are deeply hidden under the layers of tool (rush, heft, gulp, …) which make practically impossible to tweak without some hijacking. Not using the latest React 18 (which is 2 years old now) prevent us to use some very nice 3rd part lib (react query!), unit testing is incredibly complex, …

But to be honest, I can’t really blame Microsoft. I guess design choices are made to target large scale teams where consistency and reliability is more important than “Hype drive development”. The nodejs world is a big mess. There are plenty of different ways to achieve some tasks, from easier to very complex ones. The MS approach tends to rationalize how everything works, and the resulting support is easier.

There is probably a middle ground to find. Improving extensibility without sacrificing reliability and consistency. Decoupling build from SPFX version is a small but great step into this direction.

Steve Beaugé (@stevebeauge)

Steve Beaugé (@stevebeauge) I'm not sure what “Hype drive development” means or why consistency and reliability are blocks to having an up-to-date tool-chain.

The following quotes are from Microsoft's own literature

With the SharePoint Framework, you can use modern web technologies and tools in your preferred development environment

It's framework-agnostic. You can use any JavaScript framework that you like including, but not limited to, React, Handlebars, Knockout, Angular, and Vue.js.

How can you be framework-agnostic and modern if you're forced to use an ancient version of TypeScript? Where are the getting started guides for using alternative frameworks other than the bundled React version in use by SharePoint?

All they have to do is create a custom/advanced option in yeoman that just expects a path to a bundle css/js files. That bundle could just be an external bundle (so that the SPFx webpack configs can be completely separate from the "custom app's" webpack configs, or the custom app might not even use webpack at all). Also, publish an npm package that gives you a modern SPFx context object

import * as React from "react";
import { getContext, WebPartContext } from "@microsoft/sp-webpart-base";
//-------^^^^^^^^^^- This can just be the onInit method in the BaseClientSideWebPart class
// that returns a context instead of just initializing `this.context`
// (and whatever else it might do).
// All we're doing here is following the age-old "composition over inheritance" principle.


// This becomes your entrypoint that you code and build in whatever
// way you want, as long as it gets bundled into a js and css file SPA App
export function App(): JSX.Element {
  const [state, setState] = React.useState<SPFX_CONTEXT_INIT_STATE>({
    _type: "IDLE",
  });
  React.useEffect(() => {
    setState({ _type: "LOADING" });
    // This is how we get our `this.context` assuming the code runs
    // inside a modern page, bootstrapped by SPFx
    getContext()
      .then((spfxContext) => {
        setState({ _type: "SUCCESS", spfxContext });
      })
      .catch((error) => {
        setState({ _type: "ERROR", error });
        console.log("SPFx context error", error);
      });
  }, []);

  switch (state._type) {
    case "IDLE":
      return <div>First render. Should automatically go to loading</div>;
    case "LOADING":
      return <div>Loading...</div>;
    case "SUCCESS":
      // This is how you'd bootstrap your own app
      return <PageRouter spfxContext={state.spfxContext} />;
    case "ERROR":
      return (
        <div>{`Check console for "SPFx context error". Is this app running inside a modern SharePoint page?`}</div>
      );
    default:
      absurd(state);
      return <div>satisfying return type signature</div>
  }
}

// Nevermind this stuff
declare function PageRouter(props: {
  spfxContext: WebPartContext;
}): JSX.Element;
declare function getContext(): Promise<WebPartContext>;

type IDLE = { _type: "IDLE" };
type LOADING = { _type: "LOADING" };
type SUCCESS = { _type: "SUCCESS"; spfxContext: WebPartContext };
type ERROR = { _type: "ERROR"; error: unknown };

type SPFX_CONTEXT_INIT_STATE = IDLE | LOADING | SUCCESS | ERROR;

function absurd<A>(_: never): A {
  throw new Error("absurd");
}

Extensions and properties can work in a similar way where you just import a subscriber function that lets you listen to events (like command button presses or page navigation events, etc...).

The disadvantages would be that the final solution would be bigger and the build process would be more complicated but those are tradeoffs that you must allow the developer to decide on (and by extension, whoever the developer's client is)

smolattack

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

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

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

How do I reopen it? It says I'm not authorized to reopen.

smolattack

Hello smolattack,
Apologies for the inconvenience caused.
We'll connect with the engineering team to get clarity on these points and update you as soon as we have more information.
Thanks!!

This issue is more than 12 months old and has not had recent activity. We are cleaning up the backlog so we can manage incoming reports more efficiently. If the issue is still relevant, please submit a new issue with updated details and current reproduction steps. We apologize for any inconvenience caused by this updated process, and thank you for being part of the SharePoint developer ecosystem.

Thank you for taking the time to file an issue. We periodically archive older or inactive issues as part of our issue management process, which automatically closes them once they are archived.

If you’d like to understand more about why and how we handle archived (closed) issues, please see Our approach to closed issues.

We appreciate your contribution and if this is still an active issue with the latest SPFx versions, please do resubmit the details. We needed to perform a cleanup, so that we can start with a clean table with a new process. We apologize for the inconvenience this might cause.

Navigation Menu

Repository navigation

What is meant by "Buildtime packages release is decoupled from the SPFx release"? #9608

What type of issue is this?

What SharePoint development model, framework, SDK or API is this about?

Target SharePoint environment

What browser(s) / client(s) have you tested

Additional environment details

Issue description

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

What is meant by "Buildtime packages release is decoupled from the SPFx release"? #9608

Description

What type of issue is this?

What SharePoint development model, framework, SDK or API is this about?

Target SharePoint environment

What browser(s) / client(s) have you tested

Additional environment details

Issue description

Activity

s-KaiNet commented on Mar 28, 2024

smolattack commented on Mar 28, 2024

VesaJuvonen commented on Apr 3, 2024

smolattack commented on Apr 4, 2024

stevebeauge commented on Apr 10, 2024

smolattack commented on Apr 10, 2024

Amey-MSFT commented on Jun 23, 2025

Amey-MSFT commented on Jul 7, 2025

smolattack commented on Jul 16, 2025

Amey-MSFT commented on Jul 17, 2025

VesaJuvonen commented on Nov 3, 2026

github-actions commented on Nov 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions