Support Multiple SPFx versions

[Adam-it]

🎯 Aim

Currently SPFx Toolkit usually supports latest version of SPFx. Although it may work with older versions of SPFx than latest, usually many features of this Toolkit default to this. So the aim is to rebuild this behavior and try to add support to more (best all) SPFx versions possible.

✅ The Plan

In order to allow to support all SPFx version possible we need to rethink/refactor the following functionalities:

• [x] #515 - here we validate node and global packages if they are up to date with latest version of SPFx and we have our own custom logic around that. What I was thinking is to refactor it so that first we would run the m365 spfx doctor command. This command checks the globally installed SPFx generator and when it is found it validates the version of Node, gulp-cli, and yo if they are compatible with the SPFx generator. This is exactly what we need! aaaand on top of that if the command fails (so it will not find any SPFx generator package installed) we could then run our current logic which means that we will validate to the currently latest version of SPFx.

• [x] #516 - currently here we always install dependencies for latest version of SPFx. But what if we reuse this compatibility matrix (I mean store a copy of it in our code base)/ In CLI we do it this way, and present a picker (default option, so when user will just hit enter, will be always latest version of SPFx) with all SPFx versions and install the global dependencies for the selected version of SPFx? Also Node! In SPFx Toolkit we already have a setting in which dev may set if they are using NVM or NVS or none

if the dev set:

• none - then we may only check if the currently installed node version is compatible with SPFx version selected. If it is selected we proceed with installing dependencies, if it is not we fail with error message and link to install node, or NVM or NVS (like we do now)

• NVM or NVS - then we check if the currently active node version is compatible if yes we proceed and if not we present a warning informing the dev that this node version is not correct and which version of node should be active/installed with 2 actions: - abort and the dev needs to do the switch on his/hers own, - install and in this case we run either NVM or NVS install commands and then the switch/use commands to set the correct version of node.

• [ ] 'Create a new project' form ... in progress 🏗️ - Currently this form (and the add new component form) is just a static html added as webview in the product. What we would need to do is build the UI dynamically based on a JSON definition we would keep locally and we should have a JSON definition for every major SPFx version

• [ ] @spfx /new ... in progress 🏗️ - the chat participant should leverage the JSON definitions from the point above and based on this figure out the correct yo command that should be run to scaffold an SPFx solution. We need to more clarify that 🤔

• [X] 'Validate project correctness' - here we do not need to change anything 🚀🚀🚀🚀. Under the hood we use m365 spfx project doctor which determines the SPFx project version from .yo-rc.json file and based on this version it validates the project npm packages for that version. Tested it couple of times and seems we are done here ✅

• [ ] #517 - 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.

• [ ] #523 - currently this feature will create a CI/CD workflow/pipeline which is aligned with latest version of SPFx. In both GitHub workflow and Azure DevOps pipelines there is a variable in which we specify the node version and currently it is always aligned with the node version valid for latest version of SPFx. We may not do much here at the moment as this is how CLI command but we could open a issue in CLI repo to change this behavior. Best if the CLI command used under the hood would check the version of SPFx in the currently used SPFx project for that command and then based on the compatibility matrix pick the correlated Node.js version. Currently this is on hold until the related issue in CLI repo will be developed and merged

  • [ ] Related issue: https://github.com/pnp/cli-microsoft365/issues/6717
    • [ ] PR opened for the related issue: https://github.com/pnp/cli-microsoft365/pull/6766

Also I have an idea for an additional action visible in the context of SPFx project

• [ ] #518 - we may think of better name but what I was thinking is to allow an action that will run the m365 spfx doctor command in the context of the currently opened SPFx project in VS Code. In this case the CLI command check the SPFx version that is used in the project based on the .yo-rc.json file and validates if the globally installed dependencies like gulp-cli and Node version are correct for that version of SPFx 🤯. I think it is an awesome feature for folks that will open some older SPFx project and would like to quickly check if they are using correct version of Node.js and gulp-cli for that project.

[Adam-it]

'Create a new project' form ... in progress 🏗️ - Currently this form (and the add new component form) is just a static html added as webview in the product. What we would need to do is build the UI dynamically based on a JSON definition we would keep locally and we should have a JSON definition for every major SPFx version

@spfx /new ... in progress 🏗️ - the chat participant should leverage the JSON definitions from the point above and based on this figure out the correct yo command that should be run to scaffold an SPFx solution. We need to more clarify that 🤔

@Saurabh7019, @nicodecleyre regarding those points. Since in the upcoming next SPFx version 1.23 a new CLI will be used instead of Yeoman this will become even more problematic. I suggest for now we keep with the scaffolding options (create new project form and /new chat command) for the latest version of SPFx only to keep it simple. BUT what we need is to make it clear for the users so I suggest we add an issue to add some warning message or notification which will explain that scaffolding works only for the latest version of SPFx. We would show this message only after checking if user locally does not have latest version of SPFx generator (or SPFx CLI after 1.23 version) What do you think? Should I open up such an issue for now? and maybe in the future we will reconsider adding support for all SPFx version when it comes to creating projects

[nicodecleyre]

@Adam-it Totally agree with this approach 👍Let keep scaffolding locked to latest version and open up the issue

[Saurabh7019]

What do you think? Should I open up such an issue for now?

Sure.. adding a warning seems urgent. Someone using an older SPFx version and scaffolding an unsupported component could get confused by the unexpected output.

[Adam-it]

we are progressing very nicely on this issue. I will try to add the last issue with adding a notify that scaffolding for the time being is only towards the latest version of SPFx