Disable unicorn/prefer-uint8array-base64#295
Merged
Merged
Conversation
The suggested `Uint8Array.fromBase64()`/`#toBase64()` are present in the Chrome target and in Bun (the build script), but Node 24 — which runs Jest/jsdom in CI — only exposes them behind the experimental `--js-base-64` flag, so they're absent under test. Rewriting the 8 sites (which include the `encoded-payload-redact.ts` / `encoded-fixture.ts` security decode paths and their fixtures) would either break the suite or force an atob/btoa-based polyfill into jsdom that exercises the shim instead of Chrome's native impl, masking prod divergence on a decode path. Not worth it for a stylistic rule. Turn off with rationale and move the row to the "not worth ratcheting" section of #279; revisit once Node ships these unflagged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![unblocked[bot]](https://avatars.githubusercontent.com/in/166219?s=60&v=4){kind=small}
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.
Part of the #279 unicorn ratchet. This row turns out not to be a clean ratchet — it's blocked by the test runtime, not the codebase.
Why off, not error
The suggested
Uint8Array.fromBase64()/Uint8Array#toBase64():manifest.jsonrequires 148)build-injection-patterns.tsbuild script)--js-base-64flag, off by defaultThe 8 sites include two security-relevant decode paths —
encoded-payload-redact.tsandencoded-fixture.ts— plus their test fixtures. Rewriting them would either:atob/btoa-based shim into jsdom — which would then exercise the shim, not Chrome's native implementation, masking any prod divergence on a decode path (loose vs. strict last-chunk handling, base64url alphabet, whitespace). That's a new blind spot on exactly the code that least wants one.Adding that risk for a stylistic rule isn't worth it. Turning it off (rather than leaving a standing
warn) matches the project convention for intentional/blocked rules (#287, #288, #294). Revisit once Node ships these methods unflagged.Changes
extension/eslint.config.js: moveunicorn/prefer-uint8array-base64fromwarntooffwith the rationale above.Verification
bun run checkpasses (biome + tsc + eslint, exit 0); 0 errors, and the remaining warnings are only the other three Ratchet eslint-plugin-unicorn 66 rules from warning back to error #279 candidates (prefer-scoped-selector×64,no-break-in-nested-loop×27,prefer-number-coercion×15).I'll update the issue #279 table to move this row into the "Not worth ratcheting" section.
🤖 Generated with Claude Code