chore(deps-dev): bump js-yaml from 4.1.0 to 4.3.1 - #52
Conversation
Bumps [js-yaml](https://github.com/nodeca/js-yaml) from 4.1.0 to 4.3.1. - [Changelog](https://github.com/nodeca/js-yaml/blob/4.3.1/CHANGELOG.md) - [Commits](nodeca/js-yaml@4.1.0...4.3.1) --- updated-dependencies: - dependency-name: js-yaml dependency-version: 4.3.1 dependency-type: direct:development ... Signed-off-by: dependabot[bot] <support@github.com>
|
PR author is in the excluded authors list. |
| "devDependencies": { | ||
| "@redocly/cli": "2.40.0", | ||
| "js-yaml": "4.1.0", | ||
| "js-yaml": "4.3.1", |
There was a problem hiding this comment.
🟡 Automated checks still install the old library version, so the upgrade has no effect in CI
The version bump was applied to the project's dependency list but not to the continuous-integration step, which still installs the old 4.1.0 build (npm install ... js-yaml@4.1.0 at .github/workflows/foundation-gate.yml:59), so the checks keep running against the outdated copy.
Impact: The security and correctness fixes from the new version are never exercised in CI, and the version actually used there silently diverges from the one declared for the project.
Incomplete version bump: package.json vs foundation-gate workflow
package.json:13 and package-lock.json were updated to js-yaml@4.3.1, but the spec-lint job installs its own copy with npm install --no-save --no-audit --no-fund js-yaml@4.1.0 before running .github/scripts/assert-refs.mjs, which imports js-yaml (.github/scripts/assert-refs.mjs:36). The pinned CI version should be bumped in lockstep.
Prompt for agents
The dependency bump of js-yaml from 4.1.0 to 4.3.1 in package.json/package-lock.json was not applied to .github/workflows/foundation-gate.yml, where the spec-lint job explicitly installs js-yaml@4.1.0 (line 59) before running .github/scripts/assert-refs.mjs. Update the pinned version in the workflow so CI uses the same version as the project manifest, and check for any other hardcoded js-yaml versions in the repo.
Was this helpful? React with 👍 or 👎 to provide feedback.
| "devDependencies": { | ||
| "@redocly/cli": "2.40.0", | ||
| "js-yaml": "4.1.0", | ||
| "js-yaml": "4.3.1", |
There was a problem hiding this comment.
🔍 Behavior changes in 4.2.0 could affect spec parsing
The lockfile shows @redocly/cli also resolves to js-yaml@4.3.1, so both the direct dev dependency and the linter's transitive copy now share the newer parser. 4.2.0 changed scalar resolution (numbers with underscores are no longer numeric), added a maxDepth limit of 100, and rejects top-level block scalars without content indentation. openapi.yaml is parsed by .github/scripts/assert-refs.mjs:36 and by redocly, so if the spec ever contains deeply nested structures or underscore-formatted numeric literals the parse result could differ from before. Worth a quick CI run to confirm lint and $ref assertions still pass.
Was this helpful? React with 👍 or 👎 to provide feedback.
| "devDependencies": { | ||
| "@redocly/cli": "2.40.0", | ||
| "js-yaml": "4.1.0", | ||
| "js-yaml": "4.3.1", |
There was a problem hiding this comment.
🟨 CI still pins the pre-patch YAML parser version
The dependency was upgraded to 4.3.1 in package.json:13 (which includes DoS/quadratic-complexity fixes for YAML merge and !!omap), but the spec-lint CI job still installs the old 4.1.0 build (npm install ... js-yaml@4.1.0 at .github/workflows/foundation-gate.yml:59) before parsing openapi.yaml via .github/scripts/assert-refs.mjs. CI therefore keeps parsing repo YAML with the unpatched parser.
Was this helpful? React with 👍 or 👎 to provide feedback.
🟢 WAVE BugBot — clearNo confident findings on the changed lines. Local review · $0 inference · wave-dispatch |


Bumps js-yaml from 4.1.0 to 4.3.1.
Changelog
Sourced from js-yaml's changelog.
... (truncated)
Commits
86e91b84.3.1 releasedc3cc4b0Backport quadratic complexity fix for !!omap33d05b54.3.0 released663bfabDrop demo publish, to not override new v5 one.1cb8c7bAdd v4-legacy tag for publish02f27afRestore umd builds back to es58be84edFix es5 compatibility59423c6ReplacemaxMergeSeqLengthoption withmaxTotalMergeKeys(more robust). Ba...6842ef6doc polish590dbab4.2.0 releasedDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.