Bug: Incorrectly resolved SPFx project upgrade rules

[waldekmastykarz]

Let me just share what is different between the two sets of instructions.

From 1.12.0 to 1.13 beta:

./config/copy-assets.json
-------------------------
Update copy-assets.json deployCdnPath:
{
  "deployCdnPath": "./release/assets/"
}

./config/deploy-azure-storage.json
----------------------------------
Update deploy-azure-storage.json workingDir:
{
  "workingDir": "./release/assets/"
}

./.gitignore
------------
To .gitignore add the 'release' folder:
release

From 1.12.1 to 1.13 beta:

./config/copy-assets.json
-------------------------
Update copy-assets.json deployCdnPath:
{
  "deployCdnPath": "temp/deploy"
}

./.gitignore
------------
From .gitignore remove the 'release' folder:
release

So at the end of the day, if I compare my project upgraded from 1.12.0 and my project upgraded from 1.12.1, the files copy-assets.json and .gitignore are different.

Originally posted by @PathToSharePoint in https://github.com/pnp/cli-microsoft365/issues/2607#issuecomment-886075322

[waldekmastykarz]

@PathToSharePoint thanks again for pointing it out. The issue is more complicated than what I originally thought. Typically, we'd handle such differences by adding superseded information to the rule. The problem in this case though is that it's the same rule which is checked against the original value of the file rather than the value as it would be modified by the rule applied from the previous version. Because each rule is executed independently, the 1.12.0 > 1.13.0 update isn't catching the fact that v1.12.1 is changing the file and all seems good while in reality you end up with an incorrect project. We'll need to think about it how to handle it properly. Thanks again. Awesome catch! 👏

[PathToSharePoint]

@waldekmastykarz I'm glad that helped. Maybe the easy way is to discard 1.12.0 upgrades? I might be the only one running that version :-)

[waldekmastykarz]

Right, the challenge is how to determine which rules to discard. From all the changes that are suggested between 1.12.0 > 1.12.1 and 1.12.1 and 1.13.0 only two need to be replaced. I have a possible solution in mind but need to check if it would work properly.

[PathToSharePoint]

While I'm at it: is it expected that devDependencies don't upgrade?

[waldekmastykarz]

They should. Let's take it to a separate issue and double check all is working as expected.

[waldekmastykarz]

@pnp/cli-for-microsoft-365-maintainers any ideas how we could solve this short from implementing a virtual file system where we can modify files and have rules work on these virtual files instead of the actual files that we collected from a project?

[waldekmastykarz]

Since we're not applying changes automatically, this would be a huge change to how we deal with SPFx upgrade. I doubt that it's worth the effort given that it occurred only once and we didn't get much traction on this issue. Closing for now and we can always revisit it in the future if need be.