Conversation
When binding.gyp builds more than one target into build/Release or build/Debug (e.g. an addon plus a test_extension), the first .node file found by readdir could be the wrong one. Prefer the literal target names declared in binding.gyp, then the normalized package name, falling back to the first match as before.
readdir order is filesystem-defined, so a fixture can already return the preferred .node first and the new tests pass without the production change. Force the decoy name first.
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.
node-gyp-buildpicks the wrong.nodefile whenbuild/Releaseholds more than one.getFirstreturns the first entry matching a generic pattern, and directory order is arbitrary, so a package
that builds several addons, or leaves an old artifact behind, can load one that is not its own.
node-gyp-build.jsnow collects the names the binding could legitimately have and prefers a matchamong them.
candidateNamesreads everytarget_nameout ofbinding.gyp, which is what the buildactually produces, and adds the package name normalised the way node-gyp normalises it, dashes to
underscores and any scope dropped.
Both the Release and Debug lookups take the list, so the two cannot disagree about which addon belongs
to the package.
When nothing matches, the previous first-match behaviour is what remains, so a package whose
binding.gypcannot be read or whose output is named something else keeps loading as it did.Fixes #83