Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
New command: verify environment configuration for using the given version of SharePoint Framework #1353
Verifies environment configuration for using the specific version of the SharePoint Framework
Doesn't introduce additional options
The command is an equivalent of the
The command starts with detecting the version of the SharePoint Framework installed either locally, in the current folder, based on
Here is what I have so far:
Originally I'd check for the correct version of yo and gulp but after talking to @StfBauer we came to the conclusion that it doesn't really matter which version you use as long as you have them both installed.
Anything else that we should check for and that we're missing?
This is super cool and I CANNOT wait to see it live...gonna definitely do a video on it!
First... great idea and well done. Especially like you're not reinventing the wheel (using
What about the case for SP2016 developers who need to use Node v8? If you have Node v8 installed, does it flag that as a good / bad? Any consideration for
Is your bar to check for what's supported, or what works? For instance, Yarn/PNPM or newer Gulp?
This is for checking your environment, but what about a way to check a project? For instance, "you're using a newer version of TypeScript, but you forgot to edit the tsconfig.json."
Thanks for your feedback gents!
currently the command checks the version of Node that is currently installed on your machine and registered with the
SPFx v1.10 runs on Node v10.x so whether you have 10.18.1 or 10.19 both will pass the check. The goal of the command is (at least right now) not to get you on the latest supported version of the toolchain but any version that satisfies the requirements of the particular version of SPFx that you're using.
Not at the moment but I've considered it and now that you ask about it, it does absolutely make sense to include it to simplify fixing the environment and keep it consistent with the project upgrade command.
The command starts by detecting the version of SPFx that you want to use: either by looking for the globally installed version of
I wanted to start with what's supported because that's an easier place to start with. What works would be more practical but could be harder to verify around the edge cases. If we had a reliable source of what works, we could absolutely use it in this command and could even go as far as making a distinction between works and supported.
Yes! That would be a great addition for sure that would also fit the version matrix.
One more question to both of you: how would you name this command?
What would be your preferred name?
I don't think that's the correct order. The guidance is to always install the latest version of the generator, regardless of what you're targetting. I'd make the current project's local version of @microsoft/sp-core-library the first option.
Otherwise, if someone has v1.10 installed, but they are working on SP2016 projects, the command will never give them the proper context details we need for troubleshooting.
spfx doctor | spfx environment doctor | spfx project doctor... doctor always knows best... I like the 1st option the most, which is an alias for the 2nd.
You're right. Thanks!
Awesome....I agree! 🧡
This makes sense and you are spot-on for what I was thinking. Allowing for any supported version of Node based on the determined version of SPFx makes sense.
I dig the spfx project doctor. To me, it combines the best of both. Since spfx project upgrade is already familiar to CLI users, you get that benefit and because doctor is also familiar, it seems to be a good marriage. Additionally if in the future we find the need for some new functionality, you will already have the model in place for spfx project YadaYada