🐞 Bug report: Existing Spfx projects are not shown toolkit actions

[ervingayle]

⭐ Priority

(Low)☹️ Something is a little off

📝 Describe the bug

When upgrading an SPFx project that does not have a yo-rc file, the ability to use the toolkit actions are not shown. While this may be by design, the project scaffolding and packages may be upgraded but you still don't get the toolkit functionality in this scenario

👣 Steps To Reproduce

Leverage any SPFx project and remove the yo-rc or nvmrc files and reopen VSCode and attempt to use the SPFx Toolkit. You will notice that the toolkit does not detect or load any of the tasks including deploy to appcatalog

📜 Expected behavior

I think that an ideal scenario would be to prompt for the creation of a yo-rc or nvmrc file after before or after upgrade guidance has been generated.

📷 Screenshots

No response

❓SharePoint Framework Toolkit version

4.2.0

❓Node.js version

18.18.0

🤔 Additional context

No response

[ervingayle]

I am not sure if this is by design in which case my ask would be a feature request instead of this submission as a bug.

[Adam-it]

@ervingayle thank you for opening up the issue.
Yes currently it is by design and by checking if the file .yo-rc.json is present and it's content we determine if it is a SPFx project.

vscode-viva/src/panels/CommandPanel.ts

Lines 39 to 45 in dd599e8

	let isTeamsToolkitProject = false;
	let files = await workspace.findFiles('.yo-rc.json', '**/node_modules/**');
	if (files.length <= 0) {
	files = await workspace.findFiles('src/.yo-rc.json', '**/node_modules/**');
	isTeamsToolkitProject = true;
	}

May I kindly ask you to share the SPFx project you are upgrading? I wonder how old it is and if valid at all from very beginning as from what I recall the .yo-rc.json file should be from SPFx 1.0 so this is 2017 (almost 7 years ago).
SPFx Toolkit primary aim is to support SPFx for SharePoint Online and although any of the SPFx version will work in SPO as it is backwards compatible and we do provide upgrade steps from the very first version of SPFx we did not plan to be sooo back in time 🙂 and for example this tool does not support On-Prem solutions.

Seems to me the missing .yo-rc.json is more likely a bug in the project itself making it not valid SPFx project 🤔. We may try to develop other methods to determine if the current project is SPFx or not but I wonder if it will not introduce to many unwanted complexity for a simple case 🤔.
What do you think?

[ervingayle]

Hi @Adam-it,
Thank you for your reply.
I wrote a script that looks at the samples\web-parts folder tree and identifies all folders that are missing a yo-rc.json file. There are 58 of those cases. However, some of the folders have function or app deploy components so the true number will be less than 58.

This issue first showed up when I tried to upgrade my Octoberfest submission. The project was already at SPFx 1.16.1! It is upgraded now but here is another project at SPFx 1.20.0 with no yo-rc.json file.
https://github.com/pnp/sp-dev-fx-webparts/tree/main/samples/react-daterangepicker

The Microsoft CLI also doesn't flag this scenario. I did see a discussion here about the decision to use yo-rc.json and not depend on package.json solely so I agree with that.

My question for discussion was if there is value in detecting the existence of the file and if its not there then creating it or making a recommendation that it's created as part of updating to the latest version. I also see even more projects without a .nvmrc file. This is not a criticism of any of the projects, as it affected me, I wanted to see what was different for projects that I got from the gallery vs trying to upgrade the sample and then using winmerge, I found these two differences. Perhaps the right thing to do is not look at adding anything to the toolkit which works very well and just update the repo with the files since they apply from SPFx 1.0.

[Adam-it]

I checked the initial commit of the sample you pointed out pnp/sp-dev-fx-webparts@53f122b#diff-2b16dde63e869b8c425a4d2975b98aa39ac8a2b2298bda6464c145ed52526d18
Originally that sample was created in SPFx 1.10.0 so I installed the Node v12 and old SPFx yo generator v1.10.0 and checked and back then yo-rc.json was already created and included in the project

So to me it's a bug and it meand that sample is kinda invalid 🤔. Wouldn't you agree?
As I said I remember SPFx from very early days and TBH I think the yo-rc.json was pretty fast added as a standard file for the SPFx project.

TBH I think it is a good idea for a separate issue in the SPFx sample repo to sort it out the samples itself as SPFx Toolkit might be not the only tool/script affected by this.
That being said I also agree that I would not include in the toolkit a workaround for this problem and trying to fix a not valid state of an SPFx solution. Even if solution is veeeery old (not sure how old it would need to be) and does not have this file, then still SPFx toolkit does not aim to support every SPFx version but we rather target only the latest..

As for .nvmrc. This is not a bug and that file is totally optional. Not everybody needs to use node version manager and they might just have node installed without it or use Docker. Also NVM is not the only node manager out there. Some might use NVS and in this case it support also the .node-version config file.

[Adam-it]

@ervingayle would you like to discuss this issue any further or you thing we are aligned?
To sum up I would suggest the following:

• don't touch the .nvmrc part as this is totally optional and not required by SPFx projects
• the problem with missing .yo-rc.json should be solved in the sp-dev-samples repos by a issue created there
• I would rather not add functionalities to spfx toolkit that will kinda 'safe the world' and try to solve unsupported states of SPFx project.

What is your take on that?

[ervingayle]

Hi @Adam-it
Thank you for taking the time to write this up and consider the issue raised. I think that we are aligned. I found another item while using the toolkit that has to do with the ordering suggested steps to upgrade the projects and in some cases the use of fast-serve.
Also is there any plan to support spfx property controls or recommendations for updating pnp packages?

[Adam-it]

@ervingayle cool. Would you be so kind and help us out and create issue for missing .yo-rc.json in the sp-dev-fx-webparts so that we may track there in this repository and let the maintainer proceed with it there.
As for your other questions:

• yes the strange order of the upgrade findings is a known issue. This functionality was developed as part of CLI for Microsoft 365 and SPFx Toolkit just uses it. We already found it and have an issue open for it in the CLI repo. Currently we are struggling to find time to fix it as in October there is a lot of going on and this repo is very active and full of work.
• as for adding support for upgrade guidance for not only official SPFx packages but also our PnP packages. This idea we are already targeting in this issue. The biggest challenge here is finding the correct rules. The current upgrade and validate guidance come from comparing template projects you may scaffolding using the yeoman generator. As PnP packages are not part of the official scaffolding process and the PnP SPFx Generator is not maintained anymore it hard to add this support.

I hope the above info will help you out 👍.
Let's leave this issue open until we open an issue for the .yo-rc.json in the spfx webpart repo.

[ervingayle]

Hi @Adam-it
Thank you for providing all of this information.
An issue was opened in that repo. Here it is: Issue

[Adam-it]

Awesome. You Rock 🤩