fix(build): emit relative imports so lib/ is portable - #3
Merged
Conversation
The release guard only grepped for '@/', so it passed on a build whose alias had already been resolved — into the build machine's absolute path. 0.1.0 shipped 22 files importing from /Users/... and nothing caught it. verify-lib.sh checks the real invariant, that no specifier in lib/ is absolute, and now runs on every PR through build-library rather than only at release time. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
imports.md said both aliases are declared with absolute paths on purpose, which is what put the build machine's path into 0.1.0. The example carries no module-resolver, so nothing depended on it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
0.1.0on npm is brokenbabel-plugin-module-resolveremits the alias target verbatim. The rootbabel.config.jsdeclaredalias: { '@': path.resolve(__dirname, 'src') }, so the published build carries the path of whatever machine ranyarn prepare:22 files in the published tarball look like that. Anything importing past the entry point fails to resolve, so the package is unusable for any consumer. The
.d.tsfiles are fine —tsc-aliasalways emitted relative paths.Why the release guard missed it
The guard grepped for
@/, and@/genuinely was not there — babel had resolved the alias, just into an absolute path. The check tested the symptom instead of the invariant.scripts/verify-lib.shnow tests the invariant: no specifier inlib/may be absolute. Validated against both builds — 36 hits on the published0.1.0, exit1; clean on this branch, exit0. It runs on every PR throughbuild-library, not only at release time, so this class of break can no longer reach a tag.Commits
998d8b0alias: { '@': './src' }— the fix22bdfc4verify-lib.sh, wired intoci.ymlandrelease.yml, exposed asyarn verify:libb8ae380imports.mdsaid the absolute paths were deliberate — that claim is what shipped the bugOn the rule that said absolute was intentional
imports.mdjustified absolute aliases by "the example's babel config also transforms library files". That is stale:example/babel.config.jscarries nomodule-resolverand says so in a comment — Metro resolves@/and~/fromexample/tsconfig.json. Nothing depended on the absolute form, so the fix costs nothing.Verification
yarn typecheckclean ·yarn test99 passing ·yarn lintzero ·yarn format:checkclean · rebuiltlib/has zero absolute specifiers and zero@/.After merge
This needs a
0.1.1, and0.1.0should be deprecated on npm so nobody installs the broken tarball.🤖 Generated with Claude Code