Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

chore: follow-ups deferred from the milestone 1.1.0 reviews

Open
  • Is something wrong?
#246 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
computer-vision, documentation, performance, testing-qa

Research direction

This is a bundle of deferred maintainer follow-ups, not one task. Start with the exception-safety bug in src/cache/cache.ts and src/node_utils/_pool_node_t.ts, where a failed allocation in resize loses a pooled node, and read the matching comment at src/gms/gms.ts:281. Done means each checklist item is either fixed or explicitly deferred, and the test suite and bench scripts still pass. Most other items need project context, so leave them to a maintainer.

Written by the indexing model from the issue text.

Description

documentation enhancement

Minor findings from the task reviews of milestone 1.1.0 (#231, #233–#237, #242) that were deferred rather than fixed in those PRs. None blocks the release; each was re-checked against dev after 1.1.0 merged (7635afe). Items already fixed since (e.g. the bench-ratios append guard, the branch-pinned design links) are not listed. The exact-wheel check from the Qodo review of #244 has its own issue, #245.

Library robustness

  • cache.get_buffer is not exception-safe (pre-existing). It unlinks the head node and decrements _pool_size before node.resize() (src/cache/cache.ts), and _pool_node_t.resize deletes data before allocating the new data_t (src/node_utils/_pool_node_t.ts). If that allocation throws (e.g. an invalid or huge size), the node is lost from the shared pool for good and left without storage; a few such failures drain the pool for every module. Fix: allocate first and swap, or resize before unlinking. When fixing it, also correct the comment at src/gms/gms.ts:281, which lists "a pool that fails to grow a buffer" among the exits its finally covers — true for the buffers already borrowed, not for the node being resized.

Licensing docs

  • The README's License section links only the LGPL. Say that OpenCV-derived code (src/gms/) is under Apache-2.0, with the text in LICENSES/Apache-2.0.txt, and that the bundle banner names it.
  • The root LICENSE holds the LGPL-3.0 text only. LGPL-3.0 is a set of additional permissions on top of GPL-3.0 and expects the GPL text to accompany it; consider adding LICENSES/GPL-3.0.txt (and shipping it in files). Pre-existing.

Benchmark docs and script (from the #219 / #134 reviews)

  • bench/README.md quick start (line 6) shows npm run bench:ratios without saying it appends a record to bench/history.jsonl (only the commands table, line 174, says so).
  • The explanation of why Vitest 5's console hz differs from 1000 / period (bench/README.md:128, scripts/bench-ratios.mjs:47-51) blames timer quantisation. The measured 40–50 % gap on a 33 µs case comes from a mean of per-sample throughputs vs. the throughput of the mean latency on a right-skewed distribution. Also bench-ratios.mjs:47 says "Vitest 4 / tinybench 4"; Vitest 4.1 used tinybench 2.9.
  • bench/README.md:20 — "reproduces the same picture within the run-to-run noise" overclaims for get_gaussian_kernel size 7 and check_subset, measured in a single pass; hedge it or take more passes.
  • The measurement protocol changed with Vitest 5 (500 ms + 100 ms warm-up per case → 1000 ms + 250 ms). Note it next to the history, and add the Vitest version to the record's env.
  • benchmark.suppressExportGetterWarnings: true is load-bearing only because of Vitest 5.0.x internals (it also gates the export-getter tracker). Document a re-check for every Vitest bump: no "Benchmark Warning" output, cache steady state near 1.0×.
  • Small inaccuracies: vitest.config.mts:26 says 1.01x → 2.5x where the README and PR say 1.07x → 2.49x; bench-ratios.mjs:328 "Always exit 0" although the guards now exit 2; error rows carry the absolute file.name (previously repo-relative).
  • bench-ratios.mjs recognises an intra-library group (like gms.bench.ts) by the absence of jsfeat names; a group with a zero/missing period then falls to an error row reading "missing jsfeatNext and/or jsfeat side", which is not the cause. An explicit opt-in (e.g. a marker in the describe title) and an accurate message would be sturdier.
  • npm run bench:dist runs tests/setup/pool-balance.ts against the source copy's pool, not the bundle's, so the balance check is vacuous there.
  • GMS bench write-up (bench/README.md, GMS section): note that the noise scene is idealised (all 289 matches are inliers), and that one busier run read rotation 0.42× / rotation+scale 2.10× — the rotation paths are the load-sensitive ones.

GMS test strength and cost (from the #134 reviews; optional)

  • The order between search passes is pinned only by two hand-placed ties in gms-coverage; swapping the right-grid order or rotation-pattern rows 2↔3 / 4↔5 (which matters only on ties) passes. Add ties for grid 10 vs 14 and pattern 2 vs 3.
  • Only the train-side x float32 read is pinned by a test; add probes for the query side and for y.
  • Optional speed-up: left-cell assignment and the best-right-cell choice do not depend on the rotation pattern but are recomputed for each of the 8 patterns; hoisting them per (scale, grid type) would cut the rotation paths (rotation+scale costs 2.29× the matching step).

Issue and project hygiene

  • #232's dependency note implies a separate bump; a ^1.1.0 range already admits 1.2.0.
  • Settle which issue owns the descriptor-kind fallback test: it stays in #136 and is not in #232.
  • #171 will need @types/node (or equivalent) once tests/** is type-checked: the OpenCV fixture tests import node:* modules.
  • The README of project #15 states the adapter pin as ^0.17.0, stale once webarkit/webarkit#94 lands.
Dominant language
TypeScript
Stars
12
Forks
4
Avg merge
1d 3h
Merged PRs (30d)
23

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from webarkit/jsfeatNext

All issues in webarkit/jsfeatNext

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.