Open smolattack opened 3 months ago
s-KaiNet
commented
3 months ago 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.
smolattack
commented
3 months ago 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 @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 @VesaJuvonen did something about the dire state this product is in, instead of just adding features no one cares about (adaptive cards, etc... )
VesaJuvonen
commented
3 months ago @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.
@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
commented
3 months ago @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.
@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.
stevebeauge
commented
2 months ago 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.
smolattack
commented
2 months ago @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)
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
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?