[Regression]: "playwright.ps1 install" crashes in branches with older version when newer version was installed in another branch
Last Good Version
1.44.0
First Bad Version
1.45.0
Steps to reproduce
-
Create branch "A" where code references Microsoft.Playwright.NUnit 1.44.0
-
Run "playwright.ps1 install" - works as expected
-
Run tests - works as expected
-
Create branch "B" where code references Microsoft.Playwright.NUnit 1.45.0
-
Run "playwright.ps1 install" - works as expected
-
Run tests - works as expected
-
Change back to branch "A"
-
Run "playwright.ps1 install" - fails with error below
-
Run tests - fails with error below
ERROR: node:internal/modules/cjs/loader:1148 throw err; ^ Error: Cannot find module './clock'
Expected behavior
"playwright.ps1 install" should not fail. If the versions are incompatible/different, then playwright.ps1 should install the version it expects.
Actual behavior
"playwright.ps1 install" fails
node:internal/modules/cjs/loader:1148 throw err; ^
Error: Cannot find module './clock'
Additional context
Cleaning the solution after changing branches is a valid workaround, but wasn't necessary before.
Environment
- Operating System: Microsoft Windows 10 Pro
- CPU: Intel64
- .NET Version (TFM): [net8.0]
I can reproduce.
@campersau do you think this this is because we do CopyToOutputDirectory="PreserveNewest" and in the case of switching back to v1.44 it wouldn't write the files against because it thinks the v1.45 are newer (based on last modified timestamp) and skips them? Probably the only option is to use CopyToOutputDirectory="Always" then?
Yes, CopyToOutputDirectory="Always" would fix that. But it might increase the build time a little bit 00:00:01.66 vs 00:00:01.90 on my machine with a single project. But I am not sure we should do it. We can also say: always do a dotnet clean when rolling back to older versions. (That's the nice thing when using ItemGroups and CopyToOutputDirectory, it integrates into other msbuild / dotnet commands.)
I'll add for now the p3-collecting-feedback label, since it would regress performance and we didn't hear much backlash from the community since we added it.
For now we recommend
dotnet clean
aka. deleting the bin/ directory as a workaround.