pnp
💡 [Feature]: Refactor Upgrade project SPFx version feature to support multiple SPFx versions
🎯 Aim of the feature
~~'Upgrade project SPFx version' - So what we could do is first we could run and check if there is any SPFx-generator installed and get its version. If there isn't then we could do what we do now which is providing guidance to upgrade to latest version of SPFx. But if we will find some SPFx-generator we could run the m365 spfx project upgrade with the --toVersion option and specify the version we found in the globally installed SPFx-generator.~~
Since the PR https://github.com/pnp/vscode-viva/pull/621 introduces SPFx Compatibility Matrix with all SPFx versions I suggest that when someone would click on SPFx project upgrade we present the list of SPFx versions that are higher (later) than the version of SPFx in the current project and allow the user to pick any version of SPFx and run upgrade to it. If someone would just click enter without selecting any version of SPFx from the list we would run upgrade version to latest version of SPFx.
📷 Images (if possible) with expected result
No response
🤔 Additional remarks or comments
No response
@Saurabh7019, @nicodecleyre do you think we could open this up? This is something we already discussed internally I just moved it to GH so we may start working on it 👍
@Saurabh7019, @nicodecleyre do you think we could open this up? This is something we already discussed internally I just moved it to GH so we may start working on it 👍
Love this one 🤩 LGTM
@Saurabh7019, @nicodecleyre I was thinking on this so more and I wonder if this would be the most optimal approach.
The problem I see
It may prove a total pain if someone has some version of SPFx generator and someone would like to upgrade to some other version of SPFx, in this case we would always run upgrade to the version that someone has installed not to the required one.
For example I have a project in version 1.12.0 I have locally installed SPFx generator 1.16 but I would like to upgrade by project to version 1.18
in this case if we run project upgrade we will always end up in version I have installed locally so 1.16 and not 1.18 🤔 and I would need remove spfx generator from node version I have locally. This does not seem user friendly.
My suggestion
Since the PR #621 introduces SPFx Compatibility Matrix with all SPFx versions I suggest that when someone would click on SPFx project upgrade we present the list of SPFx versions that are higher (later) than the version of SPFx in the current project and allow the user to pick any version of SPFx and run upgrade to it. If someone would just click enter without selecting any version of SPFx from the list we would run upgrade version to latest version of SPFx.
What do you think?
Great suggestion.. adding the SPFx Compatibility Matrix has definitely simplified things.
A couple of potential issues: I am assuming we would rely on .yo-rc.json to check the current version and show only higher versions in the QuickPick. What if .yo-rc.json is missing? There are other features that won't work as they should, but this would be another one.
Also, keeping the compatibility matrix up-to-date is key now. Can this be automated somehow? or should we schedule a weekly to check for updates?
This isn't a problem, but how would the experience be if the versions list in QuickPick becomes too long? Is there a better way to present this?
@Saurabh7019 to tackle some of your feed
A couple of potential issues: I am assuming we would rely on .yo-rc.json to check the current version and show only higher versions in the QuickPick. What if .yo-rc.json is missing? There are other features that won't work as they should, but this would be another one.
Is this actually something that is valid or supported? I think that if the .yo-rc.json is missing then your project is in a not valid state and things just don't work right 🤔?
Also, keeping the compatibility matrix up-to-date is key now. Can this be automated somehow? or should we schedule a weekly to check for updates?
No we cannot automate it as to many things change dynamically. Let's look at 1.21 and 1.22, which is a total toolchain refactor. We could think of some GitHub Workflow to schedule a weekly check but I would not worry about that that much. In CLI for Microsoft 365 we have a similar compatibility matrix and we just (manually) monitor the SPFx Team work and it's progress. If we are a few days late after the official release of some SPFx version, the world will not break. Folks usually do not update to the latest version of SPFx after it went GA on the first day 😉. Also there are a lot of similar initiativies that align with SPFx version like SPFx docker images and other... so in the PnP community, many of us keep a eye on that 🙂
This isn't a problem, but how would the experience be if the versions list in QuickPick becomes too long? Is there a better way to present this?
hmm... VS Code native behavior is that if you start typing, it filters out the list of picks like search.. I think we could go with this for now 🤔.
I think that if the
.yo-rc.jsonis missing then your project is in a not valid state and things just don't work right 🤔?
hmm SPFx solutions can still function without a .yo-rc.json file. In fact, some PnP web part samples don't have this file. But let's ignore that for now.. for the SPFx Toolkit, we can treat this as a mandatory requirement.
If we are a few days late after the official release of some SPFx version, the world will not break. Folks usually do not update to the latest version of SPFx after it went GA on the first day 😉.
Makes sense.
I think that if the
.yo-rc.jsonis missing then your project is in a not valid state and things just don't work right 🤔?hmm SPFx solutions can still function without a
.yo-rc.jsonfile. In fact, some PnP web part samples don't have this file. But let's ignore that for now.. for the SPFx Toolkit, we can treat this as a mandatory requirement.
@Saurabh7019 but I think this is just not valid state of the project. I think since 1.0 version of SPFx this file was present 🤔 I will recheck today overnight to double confirm
BTW if we know there are some projects in our PnP sample gallery that do not have the yo-rc.json we should take the effort to fix it. @Saurabh7019 I think we should open a issue for it in the PnP sample gallery repo and if in some time 2-4 weeks no one will take it lets spend some time as PnP team to get this done. Would you like to take a lead on that? If not I will add it to my backlog
ok I think the idea fits. @nicodecleyre do you want to add anything else? in the mean time I will open this up and take it
BTW if we know there are some projects in our PnP sample gallery that do not have the yo-rc.json we should take the effort to fix it.
Just checked, there are 70 samples without a .yo-rc.json file across the web parts, extensions, and ACEs repos. I will open an issue for this.. but, now I feel even more strongly that we need additional checks to detect if a project is SPFx or not.
@Saurabh7019 in this case we need to research how we may determine if the project is SPFx type BUT we need keep a look out on SPFx 1.22 to have a format that would work in all versions. I wonder if this is something we can also recheck with MS SPFx Team 👍 For now lets open this up with the new approach and open a new issue to refactor the way SPFx Toolkit checks a project is SPFx type
How is that possible that 70 samples does not have this fundamental file 🤔
70 was unbelievably high indeed. The actual number is much lower. A lot of samples are empty with only a note This sample is available in the PnP Starter Kit.
But there are still quite a few without the .yo-rc.json file. I can't find anywhere in the contribution guidelines that this file must be included with the samples. Why would those repos accept this as an issue if we report it?
Should we create an issue in our repo instead to investigate this further and make the isSPFxProject check more robust if required?
70 was unbelievably high indeed. The actual number is much lower. A lot of samples are empty with only a note This sample is available in the PnP Starter Kit.
@Saurabh7019 the starter kit has the yo-rc file. It is where the solution is in the solution folder
But there are still quite a few without the .yo-rc.json file. I can't find anywhere in the contribution guidelines that this file must be included with the samples. Why would those repos accept this as an issue if we report it?
I think it should because it is just a NOT valid SPFx project structure. If I generated an SPFx project for the very first v1 this file is there
and had the required property SPFx Toolkit needs (meaning: microsoft/generator-sharepoint)
Should we create an issue in our repo instead to investigate this further and make the isSPFxProject check more robust if required?
No I disagree to that.
IMO those are just not valid SPFx projects and I will also double confirm it with the SPFx dev team.
If the .yo-rc.json file is a typical file of an SPFx project structure which was present from the very first version of SPFx then if some project does not have it then it is just not a valid state of the project, like a missing config or property in package.json or manifest.
The project should get fixed not SPFx Toolki reinventing the wheel 🙂
On top of that in SPFx 1.23 the yeoman generator will go away and will be replaced by SPFx CLI (at least this is the plan) and in this case there will be (most probably) a different ...-rc.json file with similar properties as the yo-rc.json file. In this case we will need to align SPFx Toolkit for that tooling refactor but not to fix the current SPFx version projects (below 1.21).