🦋 Changeset detected

Latest commit: 7465634

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

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

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.16%. Comparing base (8acf5ca) to head (7465634).
⚠️ Report is 8 commits behind head on main.

@@            Coverage Diff             @@
##             main    #1764      +/-   ##
==========================================
+ Coverage   81.05%   81.16%   +0.11%     
==========================================
  Files          54       54              
  Lines        2264     2267       +3     
  Branches      679      682       +3     
==========================================
+ Hits         1835     1840       +5     
+ Misses        424      422       -2     
  Partials        5        5              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

For now, I'd prefer to update the dependency instead to avoid some unexpected weird breaks.

If so, we can move this change to next, and do the normal upgrade in main?

I'm opening a new PR on main with js-yaml@4 update.
After that, I can update this one so you can merge on next.

Since this PR will validate the line, it'll also fix #1301. Unless we do the validation manually with js-yaml if we wanted to, depends on how we draw the line for breaking changes.

I have opened #1772 which implements js-yaml update.

If so, we can move this change to next.

Let me know if you wish to proceed with this.
Once confirmed I'll rebase this branch.

superseded by #1772

re next branch - in general, I'm in favor of parsing using an actual parser. I've seen too many issues coming from regexes that were supposed to be "good enough". This is quite simple parsing... so I'm on the fence. For the time being... we don't need something as robust as js-yaml. Maybe we could consider writing a small compliant parser that would only focus on extracting Record<string, string>?

For me I'm fine with this loose regex approach. We can always make it strict if we find people hitting issues, or we need more flexibility down the road.

At the moment I don't think it's worth investing in writing a compliant parser until we need it.