test(compat): defer next/head serialization whitespace

[james-elicx]

Summary

• classify test/e2e/next-head/index.test.ts as deferred
• document that its remaining failure is Next.js internal HTML serialization whitespace, while vinext already preserves charset-first semantic ordering
• keep compatibility policy counts and the per-suite classification covered by tests

The original failure is in run 31439707085, job 93624401572. A targeted rerun reproduced 1 failure and 4 passes: the browser DOM contains charset, viewport, and user tags in the correct order, but vinext retains formatting whitespace between siblings while the test requires a contiguous raw substring. Existing tests/head.test.ts coverage verifies charset < viewport < user tag order directly.

Validation

• vp test run tests/compatibility-support.test.ts tests/head.test.ts (58 passed)
• vp check
• git diff --check
• independent review loop: no findings after addressing exact reason text

[james-elicx]

/bigbonk review for issues

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@vinext/cloudflare@2889

npm i https://pkg.pr.new/create-vinext-app@2889

npm i https://pkg.pr.new/@vinext/types@2889

npm i https://pkg.pr.new/vinext@2889

commit: 12b5bd1

[github-actions]

Example	Preview	Production	Original
app-router-cloudflare	preview	production
pages-router-cloudflare	preview	production
app-router-playground	preview	production	original
realworld-api-rest	preview	production
nextra-docs-template	preview	production
benchmarks	preview	production
hackernews	preview	production	original
workers-cache	preview	production
web	preview	production

[ask-bonk]

Review: test(compat): defer next/head serialization whitespace

Reviewed the diff, verified the count math, and checked the parity claim against existing coverage. This is a clean, low-risk classification change and I found no blocking issues.

Verified

• Count math is internally consistent. The suite moves from SUPPORTED_SUITE_FEATURES (36→35) into SUITE_SUPPORT_POLICY (33→34), so:
  • deferred 25→26 ✓
  • NON_SUPPORTED_SUITES 33→34 ✓
  • CLASSIFIED_SUITES stays 69 (34 + 35) and unique count stays 69 ✓ (it only changed category, not membership)
  • I confirmed all 69 keys across both maps are distinct.
• Parity claim holds. The reason ("charset order is already correct") is directly backed by tests/head.test.ts:606 ("emits charset first, then viewport, before user tags") and the client-side ordering tests (tests/head.test.ts:884-885). The remaining e2e failure being formatting whitespace between siblings — not a semantic ordering bug — is consistent with that coverage.
• vp check passes on both changed files (format, lint, types).
• vp test run tests/compatibility-support.test.ts — 5 passed.
• The new dedicated test (defers Next.js-specific next/head serialization whitespace) exactly mirrors the policy entry, so the classification is pinned against silent drift.

Non-blocking observations

1. Reason wording could be sharper. The reason says "Next.js internal HTML serialization whitespace", but the PR body describes the delta as vinext retaining formatting whitespace between siblings while the Next.js test asserts a contiguous raw substring. Since this string is surfaced on the user-facing compatibility page (page.tsx/contribution-grid.tsx), consider phrasing it so it's clear the whitespace is a rendering-output formatting difference (semantic order matches), rather than implying it's purely Next.js-internal. Minor.

2. deferred vs needs-vite-equivalent. The other deferred entries all track unimplemented features (Cache Components, PPR, segment cache). This one is a cosmetic serialization/whitespace gap where the behavior is already correct. deferred is defensible (excludes it from the supported pass rate, which is the goal), but it's a slightly different flavor from its siblings. Not worth changing unless you want the taxonomy to stay strict.

Neither observation blocks merge. The change is well-scoped and correctly tested.

[ask-bonk]

Review posted to PR #2889.

Summary

Reviewed PR #2889 (test(compat): defer next/head serialization whitespace). This is a compatibility-classification change that reclassifies test/e2e/next-head/index.test.ts from a supported suite to a deferred one. No blocking issues found.

Verified:

• Count math is fully consistent — the suite moves between two maps, so deferred goes 25→26, NON_SUPPORTED_SUITES 33→34, and CLASSIFIED_SUITES correctly stays at 69 (34 policy + 35 supported, all 69 keys unique).
• The parity claim is genuinely backed by tests/head.test.ts:606 and the client ordering tests — charset < viewport < user-tag order is directly asserted, so the residual e2e failure really is just whitespace between siblings, not a semantic bug.
• vp check and the compatibility-support test suite both pass.
• The new dedicated test pins the classification against silent drift.

Non-blocking notes I flagged:

1. The reason string says "Next.js internal HTML serialization whitespace" but the actual delta (per the PR body) is vinext retaining formatting whitespace — worth sharpening since it's user-facing on the compatibility page.
2. deferred is defensible but slightly different in flavor from the other deferred entries (which are unimplemented features vs. this cosmetic gap).

Neither observation blocks merge.

github run

[github-actions]

Performance benchmarks

Compared 8bb6d2f against base d558d62 using alternating same-runner rounds. Next.js was unchanged and skipped.

0 improved · 1 regressed · 5 within ±1.5%

Scenario	Framework	Baseline	Current	Change
Client bundle size (gzip)	vinext	135.2 KB	135.2 KB	⚫ -0.0%
Client entry size (gzip)	vinext	122.7 KB	122.7 KB	⚫ -0.0%
Dev server cold start	vinext	2.99 s	3.01 s	⚫ +0.4%
Production build time	vinext	3.07 s	3.12 s	🔴 +1.7%
RSC entry closure size (gzip)	vinext	114.2 KB	114.2 KB	⚫ -0.0%
Server bundle size (gzip)	vinext	193.0 KB	193.0 KB	⚫ -0.0%

View detailed results and traces

_{🟢 improvement · 🔴 regression · ⚫ change below 1.5% · paired base/head}

[james-elicx]

Independent policy review at exact head 8bb6d2feb5924f28dbfb604d88126b9697f233a6: NO FINDINGS.

Verified independently:

• Required targeted wrapper reproduced the stated disposition exactly: 4 passed, 1 failed, 0 skipped, retry 0/0 for test/e2e/next-head/index.test.ts.
• The sole failure is a contiguous raw-HTML substring assertion. The received HTML has charset → viewport → user meta in the correct order, with only formatting newlines/indentation between siblings.
• tests/head.test.ts directly pins that semantic ordering; focused validation passed 58/58 across tests/head.test.ts and tests/compatibility-support.test.ts.
• Manifest accounting is correct: this suite moves from supported to deferred, deferred/non-supported counts increase by one, and 69 classified unique suites remain unchanged.
• vp check and git diff --check pass; PR head and merge state remain exact/CLEAN.

[james-elicx]

/bigbonk review for issues

[ask-bonk]

Review: test(compat): defer next/head serialization whitespace

Independent re-review at head 8bb6d2f. Verified the diff directly against the commit (not the merged working tree, which also contains the sibling import-conditions stack). No blocking issues.

Verified against the actual PR commit (8bb6d2f)

• The commit is clean and scoped exactly to the description. It only (a) adds the next-head deferred entry to SUITE_SUPPORT_POLICY, (b) removes next-head from SUPPORTED_SUITE_FEATURES, and (c) updates the count assertions. The import-conditions/react-version rename that shows up in a range diff belongs to the sibling stacked commit (e32186d), not this PR.
• Count math is internally consistent for this commit. Recomputed from the raw source:
  • deferred: 5 (cache) + 4 (PPR) + 16 (segment) + 1 (inline next-head) = 26 ✓
  • needs-vite-equivalent: 2 (VITE_RUNTIME_CONDITIONS) + 1 (inline worker) = 3 ✓
  • unsupported: 4 (bundler) + 1 (experimental React) = 5 ✓
  • NON_SUPPORTED_SUITES = 34 (was 33), CLASSIFIED_SUITES = 69, unique = 69 — the suite only changed category, so total/unique membership is unchanged. All 69 keys distinct. ✓
• The deferred vs needs-vite-equivalent taxonomy has no numeric effect on the headline rate. bucketSupportedPassRate (router-buckets.ts:139-145) only counts status === "supported"; all three non-supported statuses are excluded equally. Moving next-head out of supported correctly drops its failing e2e test from the supported-pass-rate denominator, which is the stated goal.
• Parity claim holds. tests/head.test.ts:606 ("emits charset first, then viewport, before user tags") asserts the semantic ordering directly via index comparison (charsetIdx < viewportIdx < userIdx, lines 616-622), and the client-sync tests (tests/head.test.ts:884-885) pin SSR order. This confirms the residual e2e failure is genuinely inter-sibling whitespace, not a semantic ordering bug.
• vp check passes on both files (format, lint, types). vp test run tests/compatibility-support.test.ts tests/head.test.ts — 59 passed.
• The new dedicated test mirrors the policy entry exactly, pinning the classification against silent drift.

Non-blocking observations

1. Reason wording is slightly inverted. The reason reads "Next.js internal HTML serialization whitespace", but per the PR body the actual delta is that vinext retains formatting whitespace between siblings while the Next.js test asserts a contiguous raw substring. Since this string is surfaced on the user-facing compatibility page, phrasing it as a rendering-output formatting difference (semantic order matches) rather than a "Next.js internal" issue would read more accurately. Minor.

2. Taxonomy flavor. The other deferred entries track unimplemented features (Cache Components, PPR, segment cache); this one is a cosmetic whitespace gap where the behavior is already semantically correct. deferred is defensible since the outcome (excluded from the supported rate) is identical, but it's a different flavor from its siblings. Not worth changing unless you want the taxonomy strict.

Neither observation blocks merge. The change is well-scoped, correctly counted, and properly tested.

[ask-bonk]

Review posted to PR #2889.

Summary

Reviewed PR #2889 (test(compat): defer next/head serialization whitespace) independently at head 8bb6d2f. No blocking issues found.

Key verification: I checked the actual PR commit (8bb6d2f) rather than a range diff — the range diff misleadingly includes changes from the sibling stacked PR (the import-conditions/react-version rename in commit e32186d). The PR's own commit is clean and matches the description exactly:

• Adds next-head as a deferred policy entry
• Removes it from SUPPORTED_SUITE_FEATURES
• Updates count assertions

Verified:

• Count math recomputed from raw source is internally consistent: deferred 25→26, needs-vite-equivalent 3, unsupported 5, NON_SUPPORTED_SUITES 33→34, CLASSIFIED_SUITES stays 69 (all keys unique — suite only changed category).
• The deferred vs needs-vite-equivalent taxonomy has zero numeric impact — bucketSupportedPassRate counts only supported, so all non-supported statuses are excluded equally. Moving next-head out of supported correctly drops the failing e2e from the denominator.
• Parity claim holds: tests/head.test.ts:606 asserts charset < viewport < user-tag ordering directly, confirming the residual e2e failure is inter-sibling whitespace, not a semantic bug.
• vp check passes; tests/compatibility-support.test.ts + tests/head.test.ts = 59 passed.

Non-blocking notes: (1) the reason string reads "Next.js internal HTML serialization whitespace" but the real delta is vinext retaining whitespace — worth sharpening since it's user-facing; (2) deferred is a slightly different flavor from its siblings (unimplemented features) but numerically equivalent, so defensible.

github run

[james-elicx]

/bigbonk review for issues

[ask-bonk]

Review: test(compat): defer next/head serialization whitespace

Independent re-review at head 8bb6d2f. I verified the PR's own commit in isolation (git show 8bb6d2f), not the merged working tree, since the working tree also contains the sibling import-conditions / react-version stacked changes that would otherwise pollute a range diff. No blocking issues.

Verified against the actual PR commit (8bb6d2f)

• Scope is exactly as described. The commit only (a) adds the next-head deferred entry to SUITE_SUPPORT_POLICY, (b) removes next-head from SUPPORTED_SUITE_FEATURES, and (c) bumps the count assertions. The import-conditions/react-version reshuffle visible in the working tree belongs to the sibling stacked commit, not this PR.

• Count math is internally consistent for the commit. Recomputed from the raw source at 8bb6d2f:

  • deferred: 5 (cache) + 4 (PPR) + 16 (segment) + 1 (inline next-head) = 26 ✓
  • needs-vite-equivalent: 2 (VITE_RUNTIME_CONDITIONS) + 1 (inline worker) = 3 ✓
  • unsupported: 4 (bundler) + 1 (experimental React) = 5 ✓
  • NON_SUPPORTED_SUITES = 34 (was 33), CLASSIFIED_SUITES = 69, unique = 69. The suite only changed category, so total/unique membership is unchanged; I confirmed all 69 keys across both maps are distinct with zero duplicates.

• Taxonomy choice has no numeric effect on the headline rate. bucketSupportedPassRate (router-buckets.ts:112-114) accumulates supportedPassed/supportedFailed only when supportStatus === "supported". All three non-supported statuses are excluded equally. Moving next-head out of supported correctly drops its failing e2e test from the supported-pass-rate denominator, which is the stated goal.

• Parity claim holds. tests/head.test.ts:606 ("emits charset first, then viewport, before user tags") asserts the semantic ordering directly via index comparison (charsetIdx < viewportIdx < userIdx, lines 616-622). This confirms the residual e2e failure is genuinely inter-sibling formatting whitespace, not a semantic ordering bug.

• Quality gates pass. vp check apps/web/app/compatibility/suite-support.ts tests/compatibility-support.test.ts — format, lint, and types all clean. vitest run tests/compatibility-support.test.ts — 6 passed. The new dedicated test mirrors the policy entry exactly, pinning the classification against silent drift.

Note: in the merged working tree the assertions read deferred: 26 / needs-vite-equivalent: 2 / NON_SUPPORTED_SUITES 33 because the sibling stack moved react-version into SUPPORTED_SUITE_FEATURES. Both states are self-consistent and both test suites pass — the delta is entirely the sibling PR, not an inconsistency introduced here.

Non-blocking observations

1. Reason wording is slightly inverted. The reason reads "Next.js internal HTML serialization whitespace; charset order is already correct", but per the PR body the actual delta is that vinext retains formatting whitespace between siblings while the Next.js test asserts a contiguous raw substring. This string renders directly to users on the compatibility page (contribution-grid.tsx:268 and :467), so phrasing it as a rendering-output formatting difference (semantic order matches) rather than a "Next.js internal" issue would read more accurately. Minor.

2. Taxonomy flavor. The other deferred entries track unimplemented features (Cache Components, PPR, segment cache); this one is a cosmetic whitespace gap where behavior is already semantically correct. deferred is defensible since the numeric outcome is identical, but it's a different flavor from its siblings. Not worth changing unless you want the taxonomy strict.

Neither observation blocks merge. The change is well-scoped, correctly counted, and properly tested.

[ask-bonk]

Review posted to PR #2889.

Summary

Reviewed PR #2889 (test(compat): defer next/head serialization whitespace) independently at head 8bb6d2f. No blocking issues found.

Key methodology: I verified the PR's own commit (git show 8bb6d2f) in isolation rather than the merged working tree, since the working tree contains a sibling stacked PR (import-conditions/react-version) that would otherwise pollute the diff.

Verified:

• Scope matches the description exactly — adds next-head as a deferred policy entry, removes it from supported, bumps counts.
• Count math recomputed from raw source at the commit: deferred 26, needs-vite-equivalent 3, unsupported 5, NON_SUPPORTED_SUITES 34, CLASSIFIED_SUITES 69 (all 69 keys unique, zero duplicates). Self-consistent.
• Taxonomy has zero numeric impact — bucketSupportedPassRate counts only supported, so all non-supported statuses are excluded equally; moving next-head out correctly drops the failing e2e from the denominator.
• Parity claim holds — tests/head.test.ts:606 asserts charset < viewport < user-tag ordering directly, confirming the residual e2e failure is inter-sibling whitespace, not a semantic bug.
• Quality gates pass — vp check clean, compatibility-support test suite passes (6/6).

Non-blocking notes:

1. The reason string says "Next.js internal HTML serialization whitespace" but the real delta is vinext retaining whitespace — worth sharpening since it renders directly on the user-facing compatibility page.
2. deferred is a slightly different flavor from its siblings (unimplemented features vs. cosmetic gap), but numerically equivalent, so defensible.

I also clarified in the review that the working-tree assertions (33/2) differ from the commit's (34/3) purely because of the sibling stack, and both states are self-consistent with passing tests.

github run