In the latest versions of SPFx, there's a dependency override in the package.json
{
"devDependencies": {
"@rushstack/heft": "1.2.7"
},
"overrides": {
"@rushstack/heft": "1.2.7"
}
}
Currently when you run m365 spfx project upgrade, you get a result like below:
Notice that we have to set the dependency override at the end by hand. This is a bit problematic because if we read the document from top to bottom and adjust the dependency override at the end, the npm i command at the start will fail because the dependency override prevents the dev dependency of @rushstack/heft from being updated. So in fact, we should execute the upgrade guidance from bottom to top...
This can be enhanced! Using the npm cli, we can first set dependency overrides before running npm i. You can set one (or more) dependency overrides by running: npm pkg set overrides.@rushstack/heft=1.1.2 overrides.@anything/else=1.2.3. This way we'll prevent npm i from failing, and avoid another manual action by the user.
In the latest versions of SPFx, there's a dependency override in the
package.json{ "devDependencies": { "@rushstack/heft": "1.2.7" }, "overrides": { "@rushstack/heft": "1.2.7" } }Currently when you run
m365 spfx project upgrade, you get a result like below:Notice that we have to set the dependency override at the end by hand. This is a bit problematic because if we read the document from top to bottom and adjust the dependency override at the end, the
npm icommand at the start will fail because the dependency override prevents the dev dependency of@rushstack/heftfrom being updated. So in fact, we should execute the upgrade guidance from bottom to top...This can be enhanced! Using the npm cli, we can first set dependency overrides before running
npm i. You can set one (or more) dependency overrides by running:npm pkg set overrides.@rushstack/heft=1.1.2 overrides.@anything/else=1.2.3. This way we'll preventnpm ifrom failing, and avoid another manual action by the user.