chore(deps): bump js-yaml from 3.14.1 to 3.15.1

[dependabot]

Bumps js-yaml from 3.14.1 to 3.15.1.

Changelog

Sourced from js-yaml's changelog.

3.15.1 - 2026-07-31

Security

• [backport] Remove quadratic complexity from !!omap duplicate key detection.

3.15.0 - 2026-06-27

Added

• Added maxTotalMergeKeys (10000) loader option to limit the total number of keys processed by YAML merge (<<) across one safeLoad() / safeLoadAll() call.

[3.14.2] - 2025-11-15

Security

• Fix prototype pollution in merge (<<).

Commits

• ab85ae2 3.15.1 released
• 30a5e76 dist rebuild
• 22a8071 Backport quadratic complexity fix for !!omap
• c34b6c4 3.15.0 released
• 21e13d3 dist rebuild
• 4165c62 Add v3-legacy tag for publish
• d8ff750 Add package lock
• 24f13e7 Added maxTotalMergeKeys (10000) loader option (v5 backport)
• 9963d36 3.14.2 released
• 10d3c8e dist rebuild
• Additional commits viewable in compare view

[changeset-bot]

⚠️ No Changeset found

Latest commit: d812d66

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

<!-- deep-review -->

Deep Review

Despite the title, this diff moves js-yaml from ^4.2.0 to ^3.15.1 — a major-version downgrade, not a patch bump. Dependabot computed it against a pre-d370fb5 tree and was never rebased. Separately, base main is already broken (see the second P2), so simply closing this PR does not restore the release pipeline.

🔴 P0/P1 -- must fix

• package.json:16 -- The declared js-yaml range moves from ^4.2.0 to ^3.15.1, a major-version downgrade onto the EOL v3 line, not the 3.14.1 → 3.15.1 patch bump the commit message records.
  • Fix: Set "js-yaml": "^4.3.0" and regenerate yarn.lock so the workspace block and the resolution entry both land on the v4 line.
  • _{correctness, security, maintainability, project-standards}

🟡 P2 -- recommended

• scripts/update-chart-versions.js:10 -- Under js-yaml v3, yaml.load() defaults to DEFAULT_FULL_SCHEMA and resolves !!js/function through esprima, so this diff converts both load() call sites — here and scripts/extract-release-notes.js:12 — from safe-by-default to code-execution-capable inside a release job holding contents: write.
  • Fix: Stay on js-yaml v4 where load() is the safe schema, or pass an explicit { schema: yaml.JSON_SCHEMA } at both call sites.
  • _{security, correctness}
• .github/workflows/release.yml:35 -- Pre-existing on base: commit d370fb5 deleted the js-yaml@npm:^4.2.0 resolution and the workspace dependency line while leaving package.json at ^4.2.0, so the bare yarn step runs immutable under CI and aborts with YN0028, stalling every release since that merge.
  • Fix: Regenerate yarn.lock against ^4.3.0 on main so the manifest and lockfile agree without downgrading.
  • _{correctness, reliability, security}
• .github/workflows/helm-test.yaml:1 -- No pull_request-triggered workflow installs Node dependencies, so lockfile/manifest drift is invisible until the post-merge release.yml job fails, which is exactly how the base breakage landed unnoticed.
  • Fix: Add a yarn install --immutable job to a pull_request-triggered workflow.
  • _{reliability, testing}
• scripts/update-chart-versions.js:1 -- Neither release script has any test or CI exercise, so a js-yaml major-version swap underneath them is validated only by a live release run on main.
  • Fix: Add a golden-file test that runs update-chart-versions.js against a fixture Chart.yaml and asserts byte-exact output.
  • _{testing, correctness, security, project-standards}

🔵 P3 nitpicks (3)

• yarn.lock:609 -- @changesets/parse and read-yaml-file keep resolving js-yaml to 3.14.1 alongside the new 3.15.1 entry, so the changesets code path that actually runs during release keeps the unpatched build this PR claims to fix.
  • Fix: Add a yarn resolutions entry pinning the ^3 range to a patched build, or run yarn dedupe js-yaml.
  • _{correctness, security}
• .github/dependabot.yml -- The repo has no Dependabot config, so nothing prevents the major-version flip-flop already visible across chore(deps): bump js-yaml from 4.1.0 to 4.1.1 #164, chore(deps): bump js-yaml from 4.1.1 to 4.2.0 #230, chore(deps): bump js-yaml from 3.14.1 to 4.3.0 #236, and this PR.
  • Fix: Add .github/dependabot.yml with an ignore rule for js-yaml major-version updates so the v4 pin is not re-proposed as a downgrade.
• package.json:11 -- scripts.version shells out to npm run update-chart-versions inside a project pinned to packageManager: yarn@4.9.2; no functional impact today since node_modules is already populated by the preceding yarn step.
  • Fix: Replace npm run update-chart-versions with node scripts/update-chart-versions.js.
  • _{maintainability, reliability}

---

Reviewers (7): correctness, security, reliability, testing, maintainability, project-standards, learnings-researcher

Testing gaps:

• No regression test asserts that the loader used by the release scripts rejects !!js/function, so a future slide onto an unsafe schema would pass silently.
• scripts/extract-release-notes.js:29 exits 0 with only a warning when no matching CHANGELOG.md section is found, so a parse regression degrades to an empty release body instead of failing the release.
• charts/clickstack/tests/ is helm-unittest asserting rendered Kubernetes manifests and is structurally inapplicable to this change; no Helm-level test can cover a Node dependency swap.

_{One candidate finding was dropped during verification: a yaml.dump() reformatting risk for Chart.yaml. Every field in that file is a plain string, map, or sequence, and the dumper defaults that matter (lineWidth, quoting, noArrayIndent, sortKeys) are identical across v3 and v4, so no field round-trips differently. Two findings were suppressed below the confidence gate. Lockfile checksum authenticity for js-yaml@3.15.1 could not be verified offline.}

[github-actions]

<!-- deep-review -->

Deep Review

Scope note: this PR touches no Helm templates, values.yaml, or helm-unittest files — only package.json and yarn.lock.

🔴 P0/P1 — must fix

• package.json:16 — This moves js-yaml from ^4.2.0 to ^3.15.1, a major-version downgrade that reverts the 4.x line the repo has tracked since #164 and #230, rather than the patch-level bump the commit subject describes.
  • Fix: Restore a 4.x range such as "js-yaml": "^4.3.0" and regenerate yarn.lock so the workspace entry, a matching js-yaml@npm:^4.x resolution, and argparse@npm:^2.0.1 are all present.
  • _{correctness, security, maintainability, testing, project-standards, agent-native, learnings}

🟡 P2 — recommended

• scripts/update-chart-versions.js:10 — Both release scripts call bare yaml.load(), so the resolved major alone decides whether Chart.yaml is parsed under js-yaml 3.x's full schema, which resolves !!js/function and evaluates embedded source inside a workflow holding contents: write.

  • Fix: Pass an explicit schema at both call sites, for example yaml.load(src, { schema: yaml.JSON_SCHEMA }), so loader safety no longer depends on the resolved version.
  • _{security, correctness}

• yarn.lock:621 — The transitive js-yaml@npm:^3.13.1, js-yaml@npm:^3.6.1 group is byte-identical to base at 3.14.1, so this adds a second js-yaml 3.x copy while @changesets/parse and read-yaml-file keep running the older one.

  • Fix: Run yarn up -R js-yaml so every descriptor collapses onto a single resolution instead of leaving two 3.x installs in the tree.
  • _{correctness, maintainability}

• .github/workflows/release.yml:35 — yarn runs only in the release workflow, so neither update-chart-versions.js nor extract-release-notes.js is exercised in PR CI and a YAML-parser behavior change would first surface while cutting a release.

  • Fix: Add a PR job that installs dependencies and runs a fixture test asserting update-chart-versions.js rewrites only the version: line of a copied Chart.yaml.
  • _{testing, correctness, security, project-standards}

• yarn.lock:534 — No workflow runs yarn install --immutable on pull requests, which is why base shipped js-yaml: ^4.2.0 in package.json with no matching lock resolution for five releases after d370fb5 deleted it.

  • Fix: Add yarn install --immutable to the PR test workflow so manifest and lockfile drift fails before reaching main.
  • _{correctness, security, learnings, testing}

• .github/dependabot.yml:1 — No Dependabot config or branch-freshness guard exists, so this is the second js-yaml PR to land from a stale base after d370fb5 left the lockfile inconsistent with its own manifest.

  • Fix: Add .github/dependabot.yml with rebase-strategy: auto plus a CI check that fails when a direct dependency's semver major decreases relative to the base branch.
  • _{maintainability, learnings, security}

🔵 P3 nitpicks (3)

• scripts/update-chart-versions.js:12 — The script regenerates the whole of Chart.yaml through yaml.dump(), so under a 3.x pin a future value such as condition: yes or appVersion: 0755 would be retyped as a boolean or octal on the next release run.

  • Fix: Replace the load/dump round-trip with a targeted replacement of the version: line so no other scalar can be restyled.

• .github/workflows/update-app-version.yml:26 — Pre-existing and outside this diff, the workflow_dispatch input is interpolated unquoted into sed -i, and it is the most plausible route to controlling the YAML the release scripts parse.

  • Fix: Pass the input through an env: variable and reference it as "$TAG" inside the run block.

• AGENTS.md:9 — The standards file documents Yarn 4 and changesets but no policy for dependency version changes, leaving major-downgrade PRs entirely to reviewer judgment.

  • Fix: Document a rule stating that direct dependencies must not move backward across a major version without explicit written rationale.

---

Reviewers (7): correctness, security, testing, maintainability, project-standards, agent-native, learnings.

Testing gaps:

• No test asserts the loader schema; a fixture containing !!js/function would pin the safety property across future version changes.
• No CI gate compares direct-dependency semver majors between base and head, which is what would have caught this change.
• extract-release-notes.js has no coverage of its no-match branch, which exits 0 and would ship a release with empty notes.
• Reviewers could not execute either js-yaml major locally — no js-yaml in node_modules and no registry access — so v3-vs-v4 claims rest on documented API differences and the lockfile dependency sets, not observed output.