microsoft / playwright-dotnet

.NET version of the Playwright testing and automation library.
https://playwright.dev/dotnet/
MIT License
2.49k stars 237 forks source link

[Regression]: "playwright.ps1 install" crashes in branches with older version when newer version was installed in another branch #2959

Open rramer-web-com opened 4 months ago

rramer-web-com commented 4 months ago

Last Good Version

1.44.0

First Bad Version

1.45.0

Steps to reproduce

  1. Create branch "A" where code references Microsoft.Playwright.NUnit 1.44.0

  2. Run "playwright.ps1 install" - works as expected

  3. Run tests - works as expected

  4. Create branch "B" where code references Microsoft.Playwright.NUnit 1.45.0

  5. Run "playwright.ps1 install" - works as expected

  6. Run tests - works as expected

  7. Change back to branch "A"

  8. Run "playwright.ps1 install" - fails with error below

  9. 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]
mxschmitt commented 4 months ago

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?

campersau commented 3 months ago

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.)

mxschmitt commented 3 months ago

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.