Conversation
upgrade force-copied only .github/skills/, copilot-instructions.md and QA-STRUCTURE-GUIDE.md, so everything v1.12.0 changed under templates/ reached new projects through init.js alone. Existing installations kept the old scaffold, including the login that types the password with fill(). Section 9 applies the principle per file: overwrite what is framework-owned, warn and continue where overwriting would destroy working user code, and treat a dependency group as all-or-nothing. playwright.config.ts and global-setup.ts both require() e2e/scripts/*.js, so those five files install together or not at all - a partial install leaves a project that cannot start Playwright. Skipping the group is a consistent state; the project keeps working on what it has. Two assumptions did not survive contact with the live projects. The lane scripts are not new files free of user edits: two projects already ship hand-written lane-lock.js with their own tests, 400+ lines each. And frameworkVersion cannot select a baseline - the recorded values are 1.10.0, 1.1.3, 1.1.3 and 1.0.0, two of them malformed. Detection is content-hash based instead, over every hash shipped since v1.8.0 plus a runtime hash of the current template, so a freshly scaffolded project is not flagged user-owned and the table does not go stale. Files left user-owned are scanned for .fill(password) and reported with file and line. No textual patch: the shapes differ across projects (passwordSelector vs PASSWORD_SEL) and a wrong edit to a working login is the breakage this avoids. Verified against a copy of the most customised project: its base.ts stayed byte-identical while auth.ts and test-helpers.ts upgraded, the lane group was withheld with an explanation, and trace safety reported base.ts:156.
Without this, upgrade would deliver the new skills while leaving every existing project on the old scaffold - including the login that writes the password into Playwright traces. A security fix that does not reach installed projects is not shipped.
Minor, not major: a project with no parallelLanes config behaves exactly as before, PENDING-BROWSER adds an enum value without removing any, and the spec path change affects what init generates from now on, not what exists. The one user-visible change is engines moving from >=18 to >=20. Node 18 left maintenance in April 2025 and was never covered by CI, so this aligns the declared floor with what is actually verified.
makeLegacyProject() rebuilt a v1.11.3 installation by shelling out to `git show v1.11.3:templates/automation-scaffold/<file>`. That coupled the suite to repository history and broke in GitHub Actions, where actions/checkout does a shallow clone that fetches no tags: 10 of 12 tests failed with "fatal: invalid object name 'v1.11.3'". It would equally break inside an npm pack tarball or any exported copy of the tree. Commit the six v1.11.3 scaffold files as static fixtures under test/fixtures/legacy-v1.11.3/ and copy from there instead. Bytes are unchanged, so every fixture still hashes into SHIPPED_SCAFFOLD_HASHES and the upgrade path under test is exercised exactly as before. No production logic changed. Add a guard test asserting each fixture is both in the shipped hash table and different from the current template. Without it, a drifted fixture would be read as user-owned and silently turn the "pristine file is refreshed" tests into vacuous passes. Exclude legacy-v1.11.3/ from check-forbidden-chars.js: the archived content contains em-dashes and arrows that must not be rewritten, since editing a byte changes the hash and voids the pristine match.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Completes v1.12.0. The previous PR landed the framework changes; this makes them
reach projects that are already installed.
upgradeforce-copied only.github/skills/,copilot-instructions.mdandQA-STRUCTURE-GUIDE.md, so everything the release changed undertemplates/arrived only through
init.js- in new projects. Existing installations wouldhave taken the new skills while keeping the old scaffold, including the login
that writes the password into Playwright traces. A security fix that does not
reach installed projects is not shipped.
Section 9 applies one rule per file: overwrite what the framework owns, warn and
continue where overwriting would destroy working user code, and treat a
dependency group as all-or-nothing.
playwright.config.tsandglobal-setup.tsboth
require()e2e/scripts/*.js, so those five files install together or notat all - a partial install leaves a project that cannot start Playwright.
Two assumptions did not survive contact with the live projects. The lane scripts
are not new files free of user edits: two projects already ship a hand-written
lane-lock.jswith its own tests, over 400 lines each. AndframeworkVersioncannot select a baseline - the recorded values are
1.10.0,1.1.3,1.1.3and1.0.0, two of them malformed. Detection is content-hash based instead, overevery hash shipped since v1.8.0 plus a runtime hash of the current template, so a
freshly scaffolded project is not flagged user-owned.
Files left user-owned are scanned for
.fill(password)and reported with file andline. No textual patch: the shapes differ across projects (
passwordSelectorvsPASSWORD_SEL), and a wrong edit to a working login is the breakage this avoids.Verified against a copy of the most heavily customised project: its
base.tsstayed byte-identical while
auth.tsandtest-helpers.tsupgraded, the lanegroup was withheld with an explanation, and trace safety reported
base.ts:156.--dry-runleaves the filesystem hash unchanged.130 tests passing, up from 118.
Version: minor. A project with no
parallelLanesbehaves exactly as before.The one user-visible change is
enginesmoving to>=20, aligning the declaredfloor with what CI actually verifies.
Tagging
v1.12.0after this merges triggers the npm publish.