[polylane]

The GitHub Pages deploy for cloudvalid.com failed on every build because the static site could not load its YAML parser. The dependency install put two js-yaml majors in place, and the one Node picked for the externalized import has no default export, so static route generation stopped and nothing deployed. With a single js-yaml 4.x at the top level the build completes and the site deploys.

flowchart TD
  A["markdownlint-cli2 0.23.2 pins js-yaml 5.2.2"] --> B["bun hoists js-yaml 5.2.2 to node_modules/js-yaml"]
  C["astro 7.1.6 declares js-yaml ^4.3.0"] --> D["nested js-yaml 4.3.1 bypassed at runtime"]
  B --> E["dist/.prerender chunk keeps import yaml from js-yaml"]
  E --> F["Node resolves to hoisted 5.2.2 with no default export"]
  F --> G["build fails: generating static routes"]
  H["FIX: overrides js-yaml ^4.3.1"] -.-> B

Loading

Detection evidence

Affected: int_17ad4b457001o98datdn4tkm

Why this fix

The committed lockfile hoisted markdownlint-cli2's js-yaml 5.2.2 (an ESM-only package with no default export) to the top level, while astro kept a nested 4.x copy. Astro's prerender chunk keeps import yaml from "js-yaml" externalized, so Node resolved it to the hoisted 5.2.2 and the build aborted at "generating static routes". Pinning the top level to js-yaml 4.x restores the CommonJS copy with the default export astro expects. The main remaining check is the green CI run, which is only observable on GitHub after this merges.

Fix walkthrough

Watch the fix explained (1:22). Recorded for commit 3e906e0a7b66e6ec0e96952f0e47249cbc6bd4b8.

Out of scope

• The separate claim that the production container cannot start because the static build has no SSR entry for server.mjs is a different mechanism on the same repository and is tracked by its own issue.

Production impact: Astro build completes with a single js-yaml 4.x

The change is confined to the dependency graph of datum-cloud/cloudvalid.com (package.json overrides plus a lockfile regeneration). It pins js-yaml to a single CommonJS 4.x copy, which is the version astro and starlight declare and the version that provides the default export the externalized import needs. I reproduced the failing bun install && bun run build and the passing build after the change; bun run lint stays green because markdownlint-cli2 uses only the named load export present in 4.x. No deployed resource graph nodes are connected to this workspace, so no resource behavior is degraded.

Observability

• CI workflow Deploy Astro site to Pages -> Build with Astro step: exit code and the generating static routes log line show whether the build completes.
• Install step: node_modules/js-yaml/package.json version shows the single resolved major.

Polylane assessed this pull request at 32a0213.

Causal chain

• Signal (log template): The requested module 'js-yaml' does not provide an export named 'default'
• Surfacing site: datum-cloud/cloudvalid.com GitHub Actions workflow Deploy Astro site to Pages (Build job) at datum-cloud/cloudvalid.com:.github/workflows/astro.yml#Build with Astro step -> astro/dist/runtime/prerender/static-paths.js:51
• Mechanism: The generated prerender chunk keeps import yaml from "js-yaml" externalized. At runtime Node resolves the bare specifier from dist/.prerender/ upward to the hoisted node_modules/js-yaml, which bun resolved to the ESM-only js-yaml 5.2.2 (no default export), so the default import throws and static route generation aborts.
• Producer: dependency graph of datum-cloud/cloudvalid.com (package.json + bun.lock), at datum-cloud/cloudvalid.com:package.json
• Producer evidence:
  • bun.lock top-level "js-yaml" resolved 5.2.2 (bin/js-yaml.mjs, ESM-only); astro's copy was nested as "astro/js-yaml" 4.3.1
  • markdownlint-cli2@0.23.2 depends on js-yaml 5.2.2, the source of the hoisted ESM-only copy
  • import('js-yaml') has no default for 5.2.2; 4.3.1 supplies both default and named load
  • Local repro: build fails before the pin and completes after overrides js-yaml ^4.3.1

---

Generated by Polylane. You can ask follow-ups by mentioning @polylane in a comment.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}