chore: migrate to @harperfast/code-guidelines - #1992
Conversation
@harperdb/code-guidelines is deprecated and has been republished as @harperfast/code-guidelines; 0.1.1 is functionally identical to 0.0.6. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the development dependency '@harperdb/code-guidelines' to '@harperfast/code-guidelines' (version '^0.1.1') in 'package.json' and updates the corresponding import path in 'prettier.config.mjs'. I have no feedback to provide.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
Reviewed; no blockers found. |
0.1.1 accidentally published .claude and docs directories; 0.1.2 adds a files allowlist to package.json to exclude them. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
| "libc": [ | ||
| "glibc" | ||
| ], | ||
| "license": "Apache-2.0", |
There was a problem hiding this comment.
This lock regeneration removed the libc discriminator from all four top-level Linux RocksDB binding entries. In a minimal install using this head-side metadata, npm ci on glibc installed both @harperfast/rocksdb-js-linux-x64-glibc and @harperfast/rocksdb-js-linux-x64-musl; the packages are about 15 MB each, so every Linux install/image carries an unused binding (roughly 16 MB extra on x64). build-tools/build.sh then turns this graph into the published shrinkwrap, preserving the missing selectors. Could we keep the non-migration lock entries identical to main, or restore their libc: ["glibc"] / libc: ["musl"] fields when regenerating the lock?
There was a problem hiding this comment.
Good catch — root cause was my local npm 10.9.3, which doesn't write the libc field that npm 11 adds for platform-specific optional deps, so regenerating the lock silently stripped the glibc/musl discriminators from the RocksDB binding entries. Fixed in 38da35e: I reset the lock to main and regenerated with npm 11 (npx npm@11 install --package-lock-only). All libc fields are preserved and the diff is now scoped entirely to the @harperfast/code-guidelines subtree. Same fix applied to harper-pro#629, which had the identical issue.
sent with Claude Fable 5
The previous lock regeneration used npm 10, which drops the libc discriminator from platform-specific optional deps, causing npm ci on Linux to install both glibc and musl RocksDB bindings. Regenerated from main's lock with npm 11; the diff is now scoped to the code-guidelines subtree only. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
kriszyp
left a comment
kriszyp
left a comment
There was a problem hiding this comment.
good.
🤖 Reviewed with GPT 5.6
| "libc": [ | ||
| "glibc" | ||
| ], | ||
| "license": "Apache-2.0", |
There was a problem hiding this comment.
This lock regeneration removed the libc discriminator from all four top-level Linux RocksDB binding entries. In a minimal install using this head-side metadata, npm ci on glibc installed both @harperfast/rocksdb-js-linux-x64-glibc and @harperfast/rocksdb-js-linux-x64-musl; the packages are about 15 MB each, so every Linux install/image carries an unused binding (roughly 16 MB extra on x64). build-tools/build.sh then turns this graph into the published shrinkwrap, preserving the missing selectors. Could we keep the non-migration lock entries identical to main, or restore their libc: ["glibc"] / libc: ["musl"] fields when regenerating the lock?
2 participants
@harperdb/code-guidelineshas been deprecated and republished as@harperfast/code-guidelines. Version 0.1.2 is functionally identical to 0.0.6 — no config changes, just the new package name (0.1.2 also adds afilesallowlist so.claudeanddocsare no longer included in the published artifact).This updates the dependency, any config references (prettier/eslint/docs), and the lockfile. No new lockfiles were added.
sent with Claude Fable 5