Pass --no-frozen-lockfile in pnpm dev mode to prevent CI failures

[manolo]

Summary

• pnpm 10 auto-enables --frozen-lockfile when it detects CI environments
  (via ci-info, checking GITHUB_ACTIONS, CI, etc.)
• Flow never requests this: ciBuild defaults to false in dev mode
• When a user bumps vaadin.version and pushes, the stale pnpm-lock.yaml
  causes ERR_PNPM_LOCKFILE_CONFIG_MISMATCH in CI but works locally
• Fix: explicitly pass --no-frozen-lockfile when running pnpm install
  in dev mode (ciBuild==false), since Flow is resolving dependencies,
  not reproducing a locked build

Context

When ciBuild==true, Flow already passes --frozen-lockfile explicitly.
This change makes the non-CI path equally explicit, preventing pnpm from
silently inheriting a stricter mode based on environment detection.

Fixes #23530

[github-actions]

Test Results

 1 382 files  ±0   1 382 suites  ±0   1h 26m 25s ⏱️ - 1m 16s
 9 897 tests ±0   9 826 ✅ ±0  71 💤 ±0  0 ❌ ±0 
10 370 runs  ±0  10 290 ✅ ±0  80 💤 ±0  0 ❌ ±0 

Results for commit 6653f45. ± Comparison against base commit 982d05b.

♻️ This comment has been updated with latest results.

[Artur-]

Why? The lockfile defines the installed versions. When you upgrade Vaadin, you run dev mode or mvn install locally, and that upgrades what is needed. You cannot and should not upgrade a version in the repo and assume ”npm ci” would work. How would even the new lock file end up in the repo if you would do that?

[manolo]

The lockfile here is not user-committed, it is generated by Flow during dev mode. When a user bumps vaadin.version and pushes, CI runs dev mode but the old pnpm-lock.yaml persists. pnpm 10 auto-detects CI via ci-info (checking GITHUB_ACTIONS, CI, etc.) and activates --frozen-lockfile by default, Flow never requests this, the ciBuild property defaults to false. So the same pnpm install works locally but fails in CI.

Independently of the CI issue, isPlatformMajorVersionUpdated is inconsistent: it skips the stale lockfile copy for 24.x->25.x but not for 25.0->25.1, even though overrides change between minors too.

That said, a broader fix might be better: Flow could pass --no-frozen-lockfile explicitly in dev mode, since it is resolving dependencies, not reproducing a locked build. The version check in this PR helps for the dev-bundle copy path, but in practice a stale lockfile usually already exists on disk and the if (packageLock.exists()) return guard fires before the version check is reached.

[caalador]

This is trying to fix the wrong thing and should instead fix the issue that pnpm 10 does unexpected extra enforcing depending on the environment.

I feel the more correct fix would be to add a dev mode flag that would skip the copy from devbundle if set for use in CI environment upgrade tests.

[manolo]

I agree that changing isPlatformMajorVersionUpdated semantics is not the right approach.

Looking at this more carefully, the cleanest fix is to pass --no-frozen-lockfile explicitly when Flow runs pnpm install in dev mode. The reasoning:

• Flow is resolving dependencies, not reproducing a locked build, so --frozen-lockfile makes no sense in this context
• pnpm 10 auto-enables --frozen-lockfile when it detects CI (via ci-info, checking GITHUB_ACTIONS, CI, etc.) - Flow never requests this, but inherits it silently
• This fixes the problem at the source rather than working around it in the bundle copy logic

A dev mode flag to skip the devbundle copy would work around the symptom but not the cause: even without the bundle copy, a stale pnpm-lock.yaml already on disk triggers the same ERR_PNPM_LOCKFILE_CONFIG_MISMATCH. The --no-frozen-lockfile approach covers both paths.

I will update the PR but need a clear answer what flowers prefer for this fix

[caalador]

I would say run with --no-frozen-lockfile if dev mode build and ciBuild==false

[manolo]

I would say run with --no-frozen-lockfile if dev mode build and ciBuild==false

done

[sonarqubecloud]

Quality Gate passed

Issues
2502 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud