fix: prevent root publish, sync subpackage version, regenerate lockfile#68
Conversation
Releases v1.8.12-v1.8.17 were published from the root package.json, which has no bin field, breaking npx lacy. The real npm package lives in packages/lacy/ but had drifted to 1.8.11 because shipx only bumped the root. - Sync packages/lacy/package.json to 1.8.17 - Regenerate packages/lacy/package-lock.json (was stuck at 1.7.2) - Sync bin/lacy VERSION_FALLBACK to 1.8.17 - Add "private": true to root package.json so any future publish from root fails loudly instead of shipping a broken npm package A shipx config (or upstream shipx fix to auto-detect unpublishable roots) is still needed before the next release will publish correctly.
![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 project version to 1.8.17 across several files, including the installation script and package manifests, and marks the root package.json as private. Feedback indicates that the package-lock.json file appears to have been manually edited rather than regenerated using the npm CLI, which has introduced metadata inconsistencies. It is recommended to perform a clean regeneration of the lockfile to ensure environment stability.
| { | ||
| "name": "lacy", | ||
| "version": "1.7.2", | ||
| "version": "1.8.17", |
There was a problem hiding this comment.
The PR description mentions regenerating the lockfile, but the diff only shows manual version bumps. The full file content reveals inconsistencies in dependency metadata (e.g., picocolors version 1.2.0 resolved to 1.1.1.tgz on lines 59-60) and the presence of the legacy requires: true field (line 5). These are strong indicators that the lockfile was manually edited rather than properly regenerated using the npm CLI. Manual edits to package-lock.json are error-prone and can lead to installation failures or inconsistent environments. Please perform a clean regeneration by running npm install within the packages/lacy/ directory.
There was a problem hiding this comment.
Done in 6c6292b — rm -rf packages/lacy/{node_modules,package-lock.json} then a full npm install so npm writes a coherent lockfile from scratch. The picocolors mismatch (version: 1.2.0 / resolved: 1.1.1.tgz) is gone — both fields are now 1.1.1.
Gemini noticed the lockfile had inconsistent metadata after the previous --package-lock-only regen: node_modules/picocolors had version "1.2.0" but resolved/integrity pointed at the 1.1.1 tarball. This commit removes the lockfile and node_modules, then re-runs a full `npm install` so npm writes a coherent lockfile from scratch.
1 participant
Summary
Releases v1.8.12 through v1.8.17 published the root `package.json` to npm — the root has no `bin` field, so `npx lacy` errors with "could not determine executable to run". The real npm package lives in `packages/lacy/` and had drifted to 1.8.11 because the new release tool (shipx) only bumped root.
This is a stop-gap — a proper fix in shipx (auto-detect the publishable subpackage) is in lacymorrow/shipx#49. Once that's released, lacy releases will work zero-config.
Test plan