napi is no longer output as a tag
#79
Comments
|
Def oversight! Lets just make it assume its tagged with napi if named |
|
Ok, here is the logic I'm going with; 1 . Ensure we utilize There is a potential issue here if people are not careful with their naming, e.g. - it includes some type of tag. Potentially this would be a future PR for using |
strazzere
added a commit
to strazzere/prebuildify
that referenced
this issue
Mar 7, 2024
Per issue prebuild#79 there seems to be a regression introduced in 7b6dcbd which caused the `target.runtime` to no longer be emitted when a name is used. A name is also _always_ used even if not passed, as it will grab a name from the `package.json`. This commit also dropped including the `napi` tag, which is still utilized downstream. This change fixes the regression and follows this logic; 1. Emit `name` as a tag (this will always be true due to `addName` function logic) 2. Emit `runtime` as a tag always 3. Emit `napi` as a tag if option enabled (likely always true, as it if defaulted to true)
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm unsure if this was intentional when setting
napito default, and upstream tools are meant to just "assume" that everything isnapi, however this change;7b6dcbd#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346L114-L116
Is causing prebuilt binaries to not be detected, at a minimum, by people using the tooling in
node-gyp-prebuilt. E.g. -- node-usb node-usb/node-usb#743I can submit PR with a testcase and fix for this, if you deem this an oversight on the previous patch. However if not, and this is working as intended, would you be open to a PR to enable outputing
napiexplicitly? I'm not overly familiar withnode-gypstyle prebuilds and can't tell if this was intended or not. It seems more like a bug to me.Thanks!
The text was updated successfully, but these errors were encountered: