Conversation
The 'Package build metadata for website' step only packaged */meta/*.json files — llms.txt lives at build/<category>/llms.txt, outside meta/, so it was never included in build-meta.tar.gz. The website's generate-typescript-docs.js silently skipped regenerating llms-full.txt every time (warns, doesn't fail), so helpers4.dev/typescript/llms-full.txt has been stuck at v3.0.1 through 3.0.2, 3.0.3, and 3.0.4. Verified by running the real find command against a real pnpm build output: all/llms.txt (and every per-category one) now included, tarball still under 1.5KB compressed.
Three independent bugs (missing llms.txt in the release artifact, same gap in the website's npm fallback, and a public/typescript/ that was never staged for commit) kept helpers4.dev/typescript/llms-full.txt stuck at v3.0.1 through three releases. All fixed and verified live.
baxy@etik.com was stale/wrong. Updated the root package.json (npm metadata for @helpers4/all) and both scaffolding templates (.template/bundle, .template/category) so every newly-built package carries the corrected address too — verified via a real pnpm build that the generated build/array/package.json picks it up. Same address as git commit authorship — deliberately, so npm and GitHub identities link up (verified npm email matching a GitHub commit author).
Submitted to llmstxt.site and llms-txt-hub (PR #1396) — the latter's form dropped the additional-content field, added back as a PR comment.
…on helpers median, percentile, meanBy, sumBy, mapAsync, filterAsync, forEachAsync were added without .bench.ts, unlike their siblings (mean, sum, countBy all have one) — array/ has 78% bench coverage, these seven were the gap. mapAsync/filterAsync/forEachAsync are this repo's first async benchmarks (vitest bench supports async callbacks; nothing else here had used that yet) — small vs large array, and unlimited vs concurrency-capped, since that's the actual overhead worth measuring for these (the scheduling machinery, not user work).
… *CaseKeys helpers object/ has near-100% bench coverage among its real functions (isEmpty/ isNonEmpty, guard-like state predicates, are the only pre-existing skips) — these 7 new functions were the gap.
New category, no prior bench coverage — added to match array/'s established convention for the same class of single-pass iteration operations (countBy, filter, reduce, etc. all have bench there).
Same reasoning as the map/ commit — new category, matches array/'s convention for equivalent single-pass iteration operations.
Deliberate exception to promise/'s otherwise-blanket 0% bench coverage (established when every function there was a thin Promise/setTimeout wrapper): these two have real internal state and algorithmic behavior (a FIFO queue, permit counting), much closer in kind to function/'s benched stateful factories (debounce, throttle, memoize, once) than to promise/'s typical thin wrappers.
The skill's 'create the four files' step never mentioned .bench.ts at all — a real gap, evidenced by the 31 benchmark files just added by hand for helpers scaffolded without it this session. Now points at checking the category's own existing ratio (ls *.bench.ts vs function count) instead of defaulting either way, and reminds to verify a newly added bench file actually runs.
Two related maintenance fixes bundled together for PR #120: - Tree-shaking: added `/* @__PURE__ */` before 4 module-level `new RegExp()`/`new Map()`/`new Set()` constants (helpers/color/hexToRgb.ts, helpers/guard/isCssColor.ts, helpers/object/parsePropertyPath.ts, helpers/_shared/_unsafeKeys.ts) so bundlers that can't otherwise prove these calls are side-effect-free (e.g. Rolldown) fully drop them from a consumer's bundle instead of leaving an orphaned, unused statement behind when the surrounding function goes unused. - Security audit: pnpm 10 moved the `overrides` field out of package.json's `pnpm` key into pnpm-workspace.yaml (required even for single-package repos), so this repo's override list meant to force-patch fast-uri/brace-expansion past known CVEs had been silently ignored, and the declared floors were stale besides. Migrated it to pnpm-workspace.yaml with corrected floors (fast-uri >=3.1.4, brace-expansion >=5.0.8) — `pnpm audit --audit-level low` goes from 3 high-severity findings to 0. Both packages are transitive devDependencies of @stryker-mutator/core, never shipped in the published @helpers4/* packages. - Also upgraded pnpm 10.28.2 -> 11.17.0 (added the now-required `allowBuilds: esbuild: true` to pnpm-workspace.yaml for pnpm 11's stricter default), bumped 3 devDependencies pnpm outdated flagged (fs-extra, happy-dom, oxlint), and re-pinned 2 GitHub Actions in scorecard.yml to their latest patch release SHAs. Verified against the full pipeline: typecheck, lint, 4760 tests, build (20 categories), coherency, 421/421 examples, and `pnpm audit` all pass.
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.
Description
Please include a summary of what this PR does and why it's needed.
Type of Change
Related Issues
Closes #(issue number)
How Has This Been Tested?
Describe the tests you ran and how to reproduce them:
Checklist
Screenshots (if applicable)
Add screenshots for UI changes.
Additional Context
Add any other context about the PR here.