fix(build): scope external() to own src/external tree - #224
Merged
John-David Dalton (jdalton) merged 1 commit intoAug 4, 2026
Merged
Conversation
The main build's external() treated ANY path with an external/ segment as external. That also matches a dependency's nested dist/external/* — an inlined package vendoring its own externals — externalizing modules that were meant to be bundled and emitting relative requires into files that don't exist next to the output. socket-sdk-js copied this predicate while adopting the src/external vendoring convention and its build broke exactly this way on @socketsecurity/lib's own dist/external/pony-cause; the same class of break shipped socket-cli 1.1.151's "Cannot find module 'form-data'" outage. Match by resolved path under THIS repo's src/external instead: bare specifiers stay external as before, own shims are recognized whether imported relatively or absolutely, and anything under a dependency's node_modules no longer qualifies. Behavior-preserving for this repo, proven empirically: the emitted dist is byte-identical across every .js file before and after the change (sha256 manifest compare), and the build's own export/interop validators pass unchanged. Unit tests pin the predicate semantics, including the nested-node_modules regression case.
John-David Dalton (jdalton)
deleted the
jdalton/scope-external-predicate
branch
August 4, 2026 19:33
John-David Dalton (jdalton)
added a commit
that referenced
this pull request
Aug 4, 2026
The main build's external() treated ANY path with an external/ segment as external. That also matches a dependency's nested dist/external/* — an inlined package vendoring its own externals — externalizing modules that were meant to be bundled and emitting relative requires into files that don't exist next to the output. socket-sdk-js copied this predicate while adopting the src/external vendoring convention and its build broke exactly this way on @socketsecurity/lib's own dist/external/pony-cause; the same class of break shipped socket-cli 1.1.151's "Cannot find module 'form-data'" outage. Match by resolved path under THIS repo's src/external instead: bare specifiers stay external as before, own shims are recognized whether imported relatively or absolutely, and anything under a dependency's node_modules no longer qualifies. Behavior-preserving for this repo, proven empirically: the emitted dist is byte-identical across every .js file before and after the change (sha256 manifest compare), and the build's own export/interop validators pass unchanged. Unit tests pin the predicate semantics, including the nested-node_modules regression case.
John-David Dalton (jdalton)
added a commit
that referenced
this pull request
Aug 4, 2026
…d onto the 6.5.3 release train
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.
The main build's
external()treats any path with anexternal/segment as external. That regex also matches a dependency's nesteddist/external/*— an inlined package vendoring its own externals — externalizing modules that were meant to be bundled and emitting relative requires into files that don't exist next to the output.This isn't hypothetical: socket-sdk-js copied this predicate while adopting the
src/external/vendoring convention (socket-sdk-js#681) and its build broke exactly this way — the SDK inlines@socketsecurity/lib, and the blanket match externalized lib's owndist/external/pony-cause, producingCould not resolve "../node_modules/.../dist/external/pony-cause". The same class of break (a specifier shipped with nothing behind it) is what took downsocket@1.1.151's uploads for a customer.Fix: match by resolved path under this repo's
src/external/instead. Bare specifiers stay external exactly as before; own shims are recognized whether imported relatively (../external/fast-glob.jsfromsrc/globs/_internal.ts) or absolutely; anything under a dependency'snode_modulesno longer qualifies.Behavior-preserving, proven rather than argued: the emitted
distis byte-identical across every.jsfile before and after the change (sha256 manifest of the full tree:3996e6c9deea39caboth ways), and the build's own validators pass unchanged (610 public exports, 48/51 external-module interop checks). Six unit tests pin the predicate semantics, including the nested-node_modulesregression case.Actions needed