Repository navigation
refactor: fix unicorn/no-new-array and enable it in .oxlintrc.json - #72
Merged
Merged
Conversation
Replace new Array(n) with Array.from({ length: n }) (adding an explicit
<number> type argument where TS previously inferred any[] from the
untyped new Array(n), to keep pizHuffman.ts's arithmetic on freq/
hufTableBuffer entries type-checking). Semantics are unchanged: every one
of these arrays is fully populated by index before being read (dense
Array.from vs. new Array's sparse holes doesn't matter here).
Flips unicorn/no-new-array to "error" in .oxlintrc.json, matching
canonical byte-for-byte alongside the other two tightened rules enabled
in stage 1.
Closes #71
|
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
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
2 participants
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.
Closes #71
Summary
Deferred from stage 1 (#68):
unicorn/no-new-arraywas kept"off"because turning it on surfaced 10 pre-existing errors inpizHuffman.tsandb44Codec.test.ts.new Array(n)withArray.from({ length: n })at all 8 call sites inpizHuffman.tsand 2 inb44Codec.test.ts.Array.from<number>({ length: n })type argument at the two untyped call sites (hufTableBuffer,freqinhufUncompress) —new Array(n)without an annotation inferredany[], so removing it surfaced realtscerrors (arithmetic on possibly-unknown/nullvalues) that needed the explicit type to keep compiling; behavior is unchanged since every one of these arrays is fully populated by index before being read elsewhere (the dense-vs-sparse difference betweenArray.fromandnew Arraydoesn't matter for direct index access)..oxlintrc.json: flipsunicorn/no-new-arrayto"error", now byte-identical to canonical alongside the other two tightened rules (already enabled since stage 1).Validation
pnpm build,pnpm tsc,pnpm lint,pnpm exec oxfmt --check .passpnpm exec vitest run packages/hdrify/src/exr/b44Codec.test.ts(the touched test file): 8/8 passpnpm test --coverage(full suite): running; watching PR CI on dedicated runners for the authoritative result (local EXR-decode tests intermittently time out on this machine under load, as noted in chore: standardize CI/tooling to v2 canonical (stage 1) #68/build(deps): upgrade vitest to v5 #70)node /path/to/standards/check-drift.mjs <repo>: clean, no exceptions remaining