chore(deps): js-yaml 5, and what actually changed in it - #125
Merged
Conversation
I held this back because bumping it failed fourteen tests — every workflow real-case fixture stopped detecting its rule — and on a scanner that is a false negative, which is the worst thing it can do. It turns out not to be a parsing change at all. js-yaml 5 removed the default export. `import yaml from "js-yaml"` resolves to undefined at runtime, so every call through config-parser threw and every workflow parsed as nothing. TypeScript did not catch it because the types still describe a default. One import changed to a namespace import. Two real behaviour changes came with it, and both are now pinned by tests rather than left to be discovered: **An empty document throws** where 4 returned undefined. An empty config file is an ordinary thing to find on a developer's machine and means nothing is configured — it is not a parse failure to report, so it is handled before the parser sees it. **Merge keys are no longer resolved.** `<<: *anchor` now appears as a literal "<<" key rather than merging into the mapping. Nothing in the corpus uses them and GitHub Actions rejects anchors in workflows, so no detector is affected today — but a detector reading a merged key would silently see nothing, so the behaviour is asserted where someone will find it. Comparing the two versions across nine cases, everything else is identical: `on:` keys, yes/no strings, sexagesimals, octals, duplicate-key rejection and tab-indent rejection all behave the same.
jonathansantilli
force-pushed
the
chore/js-yaml-5
branch
from
August 26, 2026 09:32
98a6fec to
5d7eb94
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I held this back from #123 because bumping it failed 14 tests — every workflow real-case fixture (RC-01…RC-11) stopped detecting its rule, plus action-file discovery. On a scanner that is a false negative, which is the worst failure it has, so it needed understanding before shipping.
It was not a parsing change. js-yaml 5 removed the default export.
import yaml from "js-yaml"resolves toundefinedat runtime, so every call throughconfig-parserthrew and every workflow parsed as nothing. TypeScript did not catch it because the shipped types still describe a default export. One import changed to a namespace import and all 14 came back.Two real behaviour changes, both now pinned by tests
An empty document throws where v4 returned
undefined. An empty config file is an ordinary thing to find on a developer's machine and means nothing is configured — not a parse failure to report. Handled before the parser sees it.Merge keys are no longer resolved.
<<: *anchornow appears as a literal"<<"key rather than merging into the mapping:Nothing in the corpus uses them and GitHub Actions rejects anchors in workflows, so no detector is affected today. But a detector reading a merged key would silently see nothing, so the behaviour is asserted where someone will find it rather than left to be rediscovered.
What did not change
Compared both versions across nine cases:
on:keys,onas a bare word, yes/no as strings, sexagesimals, octals, duplicate-key rejection, and tab-indent rejection all behave identically.882 tests pass; typecheck, lint and build clean.
Still held back
typescript7 —typescript-eslint@8.68.0(latest) still declarestypescript >=4.8.4 <6.1.0. It is not adoptable yet, and that also pins this project to TypeScript 6.0.x.