New command: SPFx project doctor
See original GitHub issueUsage
spfx project doctor
Description
Validates correctness of SPFx solution
Options
none
Additional Info
Let’s start with package.json
validation.
Here are some thoughts:
Validate SPFx Versions
We can check that SPFx packages have correct versions and version reference:
- All versions should be equal, like all are 1.13.1
^
should not be used when referencing the version. It can lead to complete versions’ mismatch
Dependencies vs DevDependencies
We can check that none of devDependencies appear in dependencies block. Examples:
- @types dependencies should not be included “dependencies”
- @microsoft/sp-build-web should be in “devDependencies” (I can provide the whole list of SPFx modules that should be in dev deps)
- Gulp, ajv
- rush-stack-compiler
Multiple Instances of rush-stack-compiler
As rush-stack-compiler modules are prefixed with the TypeScript version they’re used for, it’s easy to have multiple modules installed.
We can check for @microsoft/rush-stack-compiler-* and see if there are >1 matches.
We can even go further and check what of the versions is used in tsconfig
to display this helpful info too.
Duplicating References in Dependencies and DevDependencies
Sometimes modules can be referenced in both (I’m skipping peers to simplify it). We can easily detect it.
Duplicating Modules
This is mostly related to Fluent UI/OUIFR and PnPJS. Due to renaming, package.json
can contain reference to both fluentui and office-ui-fabric-react, as well as sp-pnp-js and @pnp/js.
We can notify the developer that he should consider removing such duplicates.
Check React and OUIFR Versions
We can validate if referenced versions of React and OUIFR are supported by the current version of SPFx.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:6
- Comments:29 (18 by maintainers)
This is a great thread, excited to see this feature come to the CLI. Would definitely benefit ISVs and partners in getting their solutions updated and help shorten the long tail of deployed versions.
If/when we can safely update the rushstack to newer versions of TS that would also be a big win, and any help we can give folks the better. We’ve considered releasing a quick package to run with npx to update the stack but held off looking forward to 1.15. Again, making this transition easy for folks is huge.
I would suspect that MOST of the code out there can be updated to newer React, TS, and other deps with no issues. Some folks using the deeper language features might have a little more work, but good 80/20 rule.
It would as well be nice to have a --whatif type mode (and you might already) where I can see what changes will be done to the package, and if it isn’t too hard a way to roll back if it suddenly doesn’t work. I guess you could just revert to before the changes as well, but anything we can do to help folks safely and comfortably upgrade is a huge plus!
The dependency cleanup would be huge - as well as detecting dependencies that are never referenced. I find stuff in PnPjs sometimes that we used in the past, still have in package.json, but long ago stopped actually using. Sometimes you just miss stuff like that and having a tool to help there would be great!
Always best to double check. I’ll get on with finalizing the command and adding tests and hopefully we’ll be able to ship it in the next few days 🚀