Improve detecting SPFx version in 'spfx doctor'

[waldekmastykarz]

Currently, the spfx doctor detects the version of SPFx framework by searching for specific packages using npm, first locally then globally. This works only if the dependencies have been already installed. In case you pulled down a project and would like to find out which version of Node.js and other tools you need to build it, the current setup will fail because it won't be able to determine the version of SPFx. You could try to install the dependencies using whatever version of Node.js you have installed. The installation will possibly fail, but it would allow you to correctly detect the SPFx version. Still the experience is suboptimal, because it requires you to install the project dependencies twice.

I think this could be a quite common use case for the spfx doctor command and we should better cater for it. One way would be, to extend the logic for detecting the SPFx version to:

• search for npm packages locally
• if local search found, search for .yo-rc.json, like we do in spfx project upgrade
• if no .yo-rc.json found, search for npm packages globally

The only possible downside is that if the contents of .yo-rc.json are not in sync with the rest of the project, we would be checking compatibility of an incorrect version. As an ultimate fallback, we could expose an additional option that allows the user to check compatibility for any version without installing any prerequisites/projects.

Thoughts @pnp/office-365-cli-maintainers?

[garrytrinder]

Sounds like a good plan @waldekmastykarz

The only possible downside is that if the contents of .yo-rc.json are not in sync with the rest of the project

Is there a way to identify that this maybe out of sync?

As an ultimate fallback, we could expose an additional option that allows the user to check compatibility for any version without installing any prerequisites/projects.

Something like spfx doctor --checkVersion 1.10?

[waldekmastykarz]

Something like spfx doctor --checkVersion 1.10?

Exactly that. The option could be that or just --version, whichever is the most intuitive to use.

Is there a way to identify that this maybe out of sync?

We've discussed it recently in the context of version detection in spfx project upgrade. In the end we decided to use .yo-rc.json as it turns out to be the only way to reliably detect SPFx project version for all SPFx versions. Especially in the past there were some inconsistencies between the SPFx version and package versions which made it hard if not impossible to detect the SPFx version. But if .yo-rc.json is not in sync with the version/range of versions then it could be problematic as well. That's why we also decided to extend the version detection logic with checking the packages in package.json and version in .yo-rc.json are in sync or not. We could use the same logic here.

[waldekmastykarz]

So, do we agree on the following enhancements?

1. Align project version detection logic between spfx project upgrade and spfx doctor where possible
2. Extend project version detection with checking if .yo-rc.json and package.json are in sync
3. Add new option version which allows to specify the SPFx version to check compatibility for, skipping the version detection

[garrytrinder]

Sounds like a good approach

[waldekmastykarz]

I've created related issues #1487, #1488 and #1489 to track the work