Files
WRNexusJS/docs/VALIDATION-0.8.3.md
T
Clintchiz 4cebacadfe
Quality / quality (ubuntu-latest) (push) Failing after 12m9s
Quality / quality (windows-latest) (push) Canceled after 0s
release: WRNexusJS 0.8.3
2026-08-03 19:47:30 +05:30

4.1 KiB

WRNexusJS 0.8.3 validation report

Validated in the prepared source archive

  • All 47 root/package manifests use version 0.8.3 and all non-workspace internal dependency ranges resolve to 0.8.3.
  • The CLI migration registry contains 0.8.3-client-ssr-realtime-stability.
  • All official package .wrn files pass parse/code-generation checks.
  • All official reusable components pass explicit-import validation.
  • The UI visual contract, public API baseline, workspace repair check, security framework audit, and ASVS policy checks pass.
  • Regression scripts verify request-derived SSR computed values, view-only browser imports, typed loop props, Async aliases, template literals in fallback expressions, native client function preservation, settings persistence, realtime identity isolation, and the TeamSpace example browser-module graph.
  • The generated VS Code compiler bundle was rebuilt from the updated syntax/compiler source.

Release-candidate corrections

After the first Windows release-gate run, the source archive was corrected for four TypeScript errors:

  • Removed the unsupported write property from Bun.build() configuration objects while keeping in-memory artifact reads through BuildOutput.outputs.
  • Typed the merged import-alias map as Record<string, string>.
  • Cast Happy DOM CustomEvent values to the exact Window.dispatchEvent parameter type in CSR tests.
  • Removed local .env and .env.uat files from the source archive; equivalent .example templates remain included.

A second Windows release-gate run exposed ten ESLint errors in release helper scripts. The source archive was corrected by importing Node globals explicitly in scripts/check-component-imports.mjs and replacing hard-counted regex spaces with {4} and {6} quantifiers in scripts/validate-0.8.mjs and update-package-versions.mjs.

A third Windows release-gate run showed that the package component validator was traversing workspace-installed dependency copies under nested node_modules directories. Those files are not first-party package sources and were being checked against the manifest of the containing workspace package. The validator now excludes dependency and generated directories (node_modules, dist, coverage, .git, .wrnexus, and .publish) while still scanning every official source component. A regression fixture confirms that an invalid nested dependency component is ignored and the 146 official source files remain validated.

A fourth Windows release-gate run found that editors/vscode/src/compiler.cjs was stale after the final compiler changes. The bundle was regenerated from all 26 current syntax/compiler TypeScript modules. A fifth Windows run then exposed a cross-environment false positive: the archive had been generated with TypeScript 5.8.3 while the frozen release install uses TypeScript 5.9.3, and the old checker compared transpiled output byte-for-byte. The editor compiler generator now normalizes source and line endings, emits source and generator SHA-256 fingerprints, and performs an exact-output check when the TypeScript version matches. When only the TypeScript patch version differs, it validates the source/generator fingerprints instead. Genuine source changes still fail the freshness gate.

The corrected helper scripts pass Node syntax checks. Package component import validation passes for all 146 official WRN files. The 0.8 validation script advances through its source-only checks in the preparation environment and stops only when dependencies excluded from the release archive are required. The complete TypeScript and Bun test gates still need to be rerun on the release machine after bun install --frozen-lockfile.

Required final release verification

The preparation environment did not include the Bun executable. Therefore the complete Bun test, lint, formatting, package build, editor bundle comparison, staged-consumer, and publish dry-run must still be executed on the release machine:

bun install --frozen-lockfile
bun run check:production
bun run release:prepare
bun run validate:staging
bun run test:staged-consumers

A release should not be published if any command above fails.