Giter Site home page Giter Site logo

prebuildify's Introduction

prebuild

A command line tool for easily making prebuilt binaries for multiple versions of Node.js, Node-API, Electron and NW.js on a specific platform.

$ npm install -g prebuild

npm Node version js-standard-style

Features

  • Builds native modules for any version of Node.js, Node-API, Electron or NW.js, without having to switch between different versions to do so. This works by only downloading the correct headers and telling node-gyp to use those instead of the ones installed on your system.
  • Upload (--upload) prebuilt binaries to GitHub.
  • Support for stripping (--strip) debug information. Strip command defaults to strip but can be overridden by the STRIP environment variable.
  • Install prebuilt modules via prebuild-install.

Building

Building is only required for targets with different ABI versions. To build for all supported ABI versions (example from leveldown):

prebuild --all

Supported ABI versions may change over time without a new prebuild release.

Alternatively, to build for some specific versions you can do:

prebuild -t 0.10.42 -t 0.12.10 -t 4.3.0

To build for Node-API, do:

prebuild -t 3 -r napi

To build against Electron headers, do:

prebuild -t 1.4.10 -r electron

To build against NW.js headers, do:

prebuild -t 0.26.6 -r node-webkit

See allTargets for all available versions.

For more options run prebuild --help. The prebuilds created are compatible with node-pre-gyp

If you'd like to include other files with your prebuilds like additional .node files or other native libraries, you can pass a file-matching regular expression to --include-regex:

prebuild -t 8.0.0 --include-regex "\.(node|a)$"

Note that if you include multiple .node files, you will need to use the prebuild-install's --binary-name parameter to indicate which file should be loaded:

prebuild-install --binary-name main-binary.node

The build file format is selected automatically by node-gyp, however it is possible to specify needed format explicitly with --format parameter. This is particularly useful if unusual flavor is required, which could be specified in 'format-flavor' form (there is no comprehensive list of formats/flavors available so one has to find possible combinations from node-gyp source code). For example, in order to build using Makefiles but assume Android cross-compilation:

prebuild --format make-android

When using the cmake-js backend additional parameters can be passed through.

prebuild --backend cmake-js -- --prefer-clang --CDUV_INCLUDE_DIR=...

Scripts

A prepack script can be specified that is executed once the .node module has been created but before it is compressed and moved. This can be used to perform code signing.

prebuild --prepack 'codesign -v -s MyCompany'

The --preinstall or --prepack parameters can take either a shell command or JS file to be executed.

Uploading

prebuild supports uploading prebuilds to GitHub releases. If the release doesn't exist, it will be created for you. To upload prebuilds simply add the -u <github-token> option:

$ prebuild --all -u <github-token>

If you don't want to use the token on cli you can put it in ~/.prebuildrc:

upload=<github-token>

Note that --upload will only upload the targets that was built and stored in ./prebuilds, so prebuild -u <github-token> -t 4.3.0 will only upload the binary for the 4.3.0 target.

You can use prebuild --upload-all to upload all files from the ./prebuilds folder.

You can use prebuild --upload --tag-prefix <prefix> for specific tag prefixes for the release. The default prefix is v and will result in a tag with an appended version number, for example v1.0.0. For lerna you can use the package name e.g. prebuild --tag-prefix some-package@ and the binaries will be released on the appropriate package's tags, for example [email protected].

You can use prebuild --upload --prerelease to create a prerelease, which will not be shown as the latest release.

Create GitHub Token

A GitHub token is needed for two reasons:

  • Create a GitHub release (leveldown example)
  • Upload the prebuilt binaries to that release

To create a token:

  • Go to this page
  • Click the Generate new token button
  • Give the token a name and click the Generate token button, see below

prebuild-token

The default scopes should be fine.

Node-API Considerations

Declaring Supported Node-API Versions

Native modules that are designed to work with Node-API, which was previously known as N-API, must explicitly declare the Node-API version(s) against which they can build. This is accomplished by including a binary property on the module's package.json file. For example:

"binary": {
  "napi_versions": [2,3]
}

In the absence of a need to compile against a specific Node-API version, the value 3 is a good choice as this is the Node-API version that was supported when Node-API left experimental status.

Modules that are built against a specific Node-API version will continue to operate indefinitely, even as later versions of Node-API are introduced.

Defining the NAPI_VERSION Value

The Node-API header files supplied with Node use the NAPI_VERSION preprocessor value supplied by the user to configure each build to the specific Node-API version for which the native addon is being built. In addition, the module's C/C++ code can use this value to conditionally compile code based on the Node-API version it is being compiled against.

prebuild supports two build backends: node-gyp and cmake-js. The NAPI_VERSION value is configured differently for each backend.

node-gyp

The following code must be included in the binding.gyp file of modules targeting Node-API:

"defines": [
  "NAPI_VERSION=<(napi_build_version)",
]

cmake-js

The following line must be included in the CMakeLists.txt file of modules targeting Node-API:

add_compile_definitions(NAPI_VERSION=${napi_build_version})

prebuild arguments

The --runtime argument must be napi to request Node-API builds. When requesting Node-API builds, the module's package.json file must include a binary property as described above. And the binding.gyp file must include a define for NAPI_VERSION as described above.

One or more --target arguments may be specified to request builds for specific Node-API versions. Node-API versions are positive integer values. Alternatively, --all may be used to request builds for all Node-API versions supported by the module.

In the absence of both --target and --all arguments, prebuild will build the most current version of the module supported by the Node instance performing the build.

Help

$ prebuild -h
prebuild [options]

  --target      -t  version     (version to build or install for)
  --runtime     -r  runtime     (Node runtime [node, napi, electron or node-webkit] to build or install for, default is node)
  --arch        -a  arch        (architecture to build or install for [default: process.arch])
  --all                         (prebuild for all known abi versions)
  --upload      -u  [gh-token]  (upload prebuilds to github)
  --upload-all  -u  [gh-token]  (upload all files from ./prebuilds folder to github)
  --tag-prefix <prefix>         (github tag prefix, default is "v")
  --preinstall  -i  script      (run this script before prebuilding)
  --prepack     -c  script      (run this script before packing, can be used to codesign)
  --path        -p  path        (make a prebuild here)
  --include-regex               (regex to match files that will be distributed [default: '\.node$'])
  --libc                        (use provided libc rather than system default)
  --backend                     (specify build backend, default is 'node-gyp')
  --format                      (specify additional parameters for `node-gyp` backend)
  --strip                       (strip debug information)
  --debug                       (set Debug or Release configuration)
  --verbose                     (log verbosely)
  --version                     (print prebuild version and exit)

JavaScript API

var prebuild = require('prebuild')

.build(opts, version, cb)

Options:

  • .log (optional)
  • .preinstall (optional)
  • .gyp Provide a custom node-gyp instance (optional)
  • .backend Provide a custom node-gyp instance via string. Alternatives are 'node-gyp', 'node-ninja', 'nw-gyp' and 'cmake-js' (optional, defaults to 'node-gyp')
  • .args Additional command line arguments to node-gyp (optional)
  • .debug Pass in --debug on command line to gyp backend (optional)

Example:

prebuild.build({}, version, function (err) {
  // ...
})

Global options:

  • .debug Download or build a debug build (default: false)
  • .arch Processor architecture (default: process.arch)

Develop prebuild

If you want to hack on prebuild you need an environment to play around with. We recommend a setup similar to the following:

  • A fork of prebuild
  • A GitHub token (see above)
  • A native node module
$ git clone [email protected]:<your-nick>/prebuild
$ cd prebuild && npm link && cd ..
$ git clone [email protected]:<your-nick>/some-native-module

Since you did npm link on prebuild it will be installed globally. Now you can go ahead and try things out.

$ cd some-native-module
$ prebuild --all --strip -u <github-token>

This command would:

  • Build some-native-module for all supported targets and store them in ./prebuilds/
  • Strip binaries from debug information
  • Create a release on GitHub, if needed
  • Upload all binaries to that release, if not already uploaded

Before you commit your changes and send us a pull request, do run npm test.

License

MIT

prebuildify's People

Contributors

ahdinosaur avatar amilajack avatar aminya avatar bcomnes avatar bjowes avatar derevnjuk avatar emilbayes avatar fanatid avatar g-ray avatar intrueder avatar jimpick avatar jschlight avatar jsumners-nr avatar kriszyp avatar mafintosh avatar mathiask88 avatar obfuscatedgenerated avatar ralphtheninja avatar vecerek avatar vweevers avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

prebuildify's Issues

document env vars

forking from #19, 🍴

here is an issue to document prebuildify's environment variables: 🌟

  • ARCH
  • PLATFORM (proposed in #20)
  • PREBUILD_ARCH
  • PREBUILD_PLATFORM
  • PREBUILD_NODE_GYP
  • STRIP (proposed in #19)

i'm also curious about the reason for both ARCH and PREBUILD_ARCH, and whether we should commit to one or the other.

cheers! ❤️

Building for Node v12.18 produces wrong ABI version

If I prebuildify with Node v12 as a target:

prebuildify --target 12.18.0

It seems to properly build the right binary, but it saves the file as node.abi68.node, which is not the correct ABI version, the correct ABI version for Node v12.18 is 72 (https://nodejs.org/en/download/releases/), so when user attempts to run the module in Node v12, it says there is no native build available (or builds/compiles as a fallback during installation).

This seems to be the case for any platform I specify.

Prebuilding for multiple target does not work with 6.0.1

We use prebuildify to prebuild for the target environments that we use and execute it something like this:

prebuildify -t 18.20.3 -t 20.13.1 -t [email protected] -t [email protected]

With version 5.0.1 this resulted in 3 prebuilds with the names:

  • node.abi108.node
  • node.abi115.node
  • electron.abi121.node
  • electron.abi123.node

After upgrading to 6.0.1 we only get 1 prebuild with the name: my-package-name.node. This means the prebuild will only work in some environments and error in others. Prebuildify still runs three builds but I assume only the last one is available in the builds folder. Platform is Windows if that matters.

Why does prebuildify have its own headers and node.lib cache?

I've been trying out prebuildify on Windows, and I noticed it has its own node headers and node.lib cache.

For example:

C:\Users\Roger Qiu\AppData\Local\node-gyp\Cache\16.14.2

Is the node-gyp cache. While

C:\Users\Roger Qiu\AppData\Local\Temp\prebuildify\node\16.14.2

Is prebuildify's node cache.

Considering that many packages are using node-gyp-install as their install script, their cache is likely populated by node-gyp automatically, why is prebuildify then creating its own cache?

I also noticed that node-gyp will automatically fill the target with the current node version. But prebuildify doesn't. Even when node-gyp was using 16.14.2, prebuildify defaulted to 18.0.0, I had to explicitly set the --target=16.14.2 when using prebuildify to ensure it was using the same.

Furthermore on Linux, once I have nodedir set, prebuildify doesn't put anything in /tmp/prebuildify, it only does it on Windows.

Bundling a shared object and data in prebuilds

More than an issue, this is a question.

I have a C library libfoo (that I wrote) that I am wrapping in a NodeJS wrapper FooNAPI. The C library is built and installed outside the NodeJS wrapper, via a Makefile. As part of the installation for the library, the Makefile puts header files in .../include/foo/, a shared object in .../lib/libfoo.so and some data files in .../share/foo/.

I can build FooNAPI by putting all the correct directories and flags in binding.gyp. Now, I would like to include libfoo.so and the files in .../share/foo/ in the FooNAPI prebuilt objects. Is there a way to do this with prebuildify? Or is this something I need to configure in binding.gyp?

If I later install the FooNAPI wrapper on another machine, and it brings in with it the shared object and the data files as part of the prebuilds, how do I get the dynamic linker on that machine to load the shared object from the node_modules/prebuilds directory?

Thanks for any hints!

Does `napi` default to true or false? Docs think false.

| `--napi` | - | `false` | Make [Node-API][node-api] build(s).<br>Targets default to latest node which is compatible with Electron > 3, which can be overridden with `--target`. Note: `--all` should be avoided for now because it includes targets that don't support Node-API.

This line is incorrect as far as I can tell:

prebuildify/bin.js

Lines 22 to 24 in d6d6981

default: {
napi: true
}

Which caused me a lot of confusion until I discovered the following through some local debugging:

#64 (comment)

prebuildify is geared towards Node-API, so the version of the executing node process is not necessarily the right version. It defaults to compiling against the latest node version

Prebuilding binaries for multiple version of the same OS

We run our module on CentOS in production, and would like our developers (who mostly have mac and Ubuntu laptops) to be able to use it locally on their boxes.

Is there any way to have the prebuilds directory contain two different versions of a shared object for the same OS, one for CentOS and one for Ubuntu? Or somehow ignoring the pre-built version from the package (which was created for CentOS) and forcing the compilation of a local one (for the case of Ubuntu)?

Or perhaps we are going about this the wrong way, and you guys have better suggestions?

how can I avoid building to node 17 ?

node 17 has a bug that it does not include a header

prebuildify/node/17.0.0/include/node/v8-persistent-handle.h:10:10: fatal error: 'v8-weak-callback-info.h' file not found
#include "v8-weak-callback-info.h"  // NOLINT(build/include_directory)

I'm using this command to build

prebuildify --all --strip

Addon compiled by `prebuildify` does not work, but the one compiled by node-gyp-build does

I'm seeing this behavior on this project. I can reproduce this all on a single Windows machine. Everything should be 64-bit (including my node.js installation), and the addon uses NAPI, so there should not be a platform mismatch.

Reproduction steps:

  1. git clone https://github.com/REVrobotics/node-can-bridge
  2. cd node-can-bridge
  3. git checkout v2.0.5
  4. npm install
  5. npm run prepublishOnly (runs prebuildify)
  6. npm install --verbose

When you run npm install --verbose, node-gyp-build sees the prebuilt addon that was built in the previous step, but it prints the following error and goes on to rebuild the addon.

node:internal/modules/cjs/loader:1280
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: \\?\C:\Users\Noah\node-can-bridge\prebuilds\win32-x64\node.napi.node is not a valid Win32 application.
\\?\C:\Users\Noah\node-can-bridge\prebuilds\win32-x64\node.napi.node
    at Object.Module._extensions..node (node:internal/modules/cjs/loader:1280:18)
    at Module.load (node:internal/modules/cjs/loader:1074:32)
    at Function.Module._load (node:internal/modules/cjs/loader:909:12)
    at Module.require (node:internal/modules/cjs/loader:1098:19)
    at require (node:internal/modules/cjs/helpers:108:18)
    at load (C:\Users\Noah\node-can-bridge\node_modules\node-gyp-build\node-gyp-build.js:22:10)
    at Object.<anonymous> (C:\Users\Noah\node-can-bridge\node_modules\node-gyp-build\build-test.js:19:19)
    at Module._compile (node:internal/modules/cjs/loader:1196:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1250:10)
    at Module.load (node:internal/modules/cjs/loader:1074:32) {
  code: 'ERR_DLOPEN_FAILED'
}

I'd appreciate any guidance for debugging this. While it's good that at least the rebuild is working correctly, it would be nice to get to the bottom of this.

[BUG] Error: spawn EINVAL

Issue

I'm playing with the following github action:

  prebuild:
    runs-on: ${{ matrix.os }}
    ...
    - name: Setup node
      uses: actions/setup-node@v4
      with:
        node-version: 20
        architecture: ${{ matrix.arch }}
    ...
    - name: Prebuild
      run: prebuildify --target 12.0.0 --napi --strip

The main idea is to run prebuildify on macos-latest:x64, ubuntu-latest:x64, windows-latest:x64 and windows-latest:x86.

Everything works fine except for the windows-latest:x86 where I get the following issue:

node:internal/child_process:414
    throw errnoException(err, 'spawn');
    ^

Error: spawn EINVAL
    at ChildProcess.spawn (node:internal/child_process:414:11)
    at Object.spawn (node:child_process:761:9)
    at D:\a\my-project\node_modules\prebuildify\index.js:230:22
    at D:\a\my-project\node_modules\mkdirp-classic\index.js:30:20
    at FSReqCallback.oncomplete (node:fs:192:23) {
  errno: -4071,
  code: 'EINVAL',
  syscall: 'spawn'

Investigation

The code in prebuildify index.js:230 is:

var child = proc.spawn(opts.nodeGyp, args, {
  cwd: opts.cwd,
  env: opts.env,
  stdio: opts.quiet ? 'ignore' : 'inherit'
})

After debugging I can see that the actual value used for opts.nodeGyp is "node-gyp.cmd":

{
  ...
  stdio: 'inherit',
  args: [
    'node-gyp.cmd',
    'rebuild',
    '--target=12.0.0',
    '--devdir=C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\prebuildify\\node',
    '--arch=ia32',
    '--release'
  ],
  detached: false,
  envPairs: [
    ...,
    ... 98 more items
  ],
  file: 'node-gyp.cmd',
  windowsHide: false,
  windowsVerbatimArguments: false
}

Solution

There seems to have some issues with spawn on Windows and most of the time people suggests to use shell: true to solve it.

So I monkey patched the previous code in prebuildify like this:

var child = proc.spawn(opts.nodeGyp, args, {
  shell: true,
  cwd: opts.cwd,
  env: opts.env,
  stdio: opts.quiet ? 'ignore' : 'inherit'
})

and it indeed solved the issue.

`napi` is no longer output as a tag

I'm unsure if this was intentional when setting napi to default, and upstream tools are meant to just "assume" that everything is napi, 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#743

I 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 napi explicitly? I'm not overly familiar with node-gyp style prebuilds and can't tell if this was intended or not. It seems more like a bug to me.

Thanks!

Upload binaries

Don't you mind if I do PR which adds option for upload binaries to github? After we can create package prebuildify-download (like prebuild-install)
This will helpful for #1

Support for node-addon-api

Hey @mafintosh! First of all: Really nice work!

I'd like to use prebuildify with node-addon-api and c++, but on requiring the prebuild with node-gyp-build the process crashed with:

internal/modules/cjs/loader.js:718
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: Module did not self-register.
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:718:18)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at load (/Users/erdii/playgrounds/n-api/cpp-example/node_modules/node-gyp-build/index.js:13:10)
    at Object.<anonymous> (/Users/erdii/playgrounds/n-api/cpp-example/index.js:1:105)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)

After investigating a bit I found out, that build/Release only contains a nothing.node when building with prebuildify, but when building with node-gyp everything is fine.

Am I missing something here?

The project is uploaded here: https://github.com/erdii/napi-cpp-example

index.js has both require-lines with the node-gyp-build one commented out.
npm run _prebuild runs prebuildify --napi and npm run build runs node-gyp rebuild.
To require the module run node index.js or node example.js.

Thank you very much in advance!

PS: I just watched your "Mad Science" talk on YT and the part where you boot ubuntu from the mounted torrent iso is so freakin' cool! 🎉

Cannot open input file node.lib

Getting this error only on windows builds? LINK : fatal error LNK1181: cannot open input file 'C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\prebuildify\\node\\18.0.0\\x86\\node.lib' [D:\a\libuiohook\libuiohook\build\kryuk.vcxproj]

log

MacOS Universal ("fat") binaries not being built?

It appears that prebuildify --napi --arch x64+arm64 is only building the first arch specified.
To test this, I created a simple NAPI demo here: https://github.com/todbot/napi-demo

After installing and verifying that demo works (and creates an arm64 build), if you npm run prebuild-darwin it will run the above prebuildify command but the resulting node.napi.node contains only one architecture. To verify only the prebuild is being tested, be sure to remove the build directory first.

An example run of doing all this is below. Am I doing something wrong or is this an actual issue. Is there a demo repo I can try that shows MacOS Universal binaries being created by prebuildify?

$ arch
arm64
$ nvm install 17.1.0
v17.1.0 is already installed.
Now using node v17.1.0 (npm v8.1.2)
$ node -p process.arch
arm64
$ git clone https://github.com/todbot/napi-demo && cd napi-demo
Cloning into 'napi-demo'...
remote: Enumerating objects: 20, done.
remote: Counting objects: 100% (20/20), done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 20 (delta 4), reused 15 (delta 3), pack-reused 0
Receiving objects: 100% (20/20), done.
Resolving deltas: 100% (4/4), done.

$ npm install

> [email protected] install
> node-gyp-build

gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | darwin | arm64
gyp info find Python using Python version 3.9.8 found at "/opt/homebrew/opt/[email protected]/bin/python3.9"
gyp info spawn /opt/homebrew/opt/[email protected]/bin/python3.9
gyp info spawn args [
gyp info spawn args   '/Users/tod/.nvm/versions/node/v17.1.0/lib/node_modules/npm/node_modules/node-gyp/gyp/gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'make',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/tod/projects/node/napi-demo/build/config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/tod/.nvm/versions/node/v17.1.0/lib/node_modules/npm/node_modules/node-gyp/addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/tod/Library/Caches/node-gyp/17.1.0/include/node/common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=/Users/tod/Library/Caches/node-gyp/17.1.0',
gyp info spawn args   '-Dnode_gyp_dir=/Users/tod/.nvm/versions/node/v17.1.0/lib/node_modules/npm/node_modules/node-gyp',
gyp info spawn args   '-Dnode_lib_file=/Users/tod/Library/Caches/node-gyp/17.1.0/<(target_arch)/node.lib',
gyp info spawn args   '-Dmodule_root_dir=/Users/tod/projects/node/napi-demo',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'build',
gyp info spawn args   '-Goutput_dir=.'
gyp info spawn args ]
gyp info spawn make
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
make: Entering directory '/Users/tod/projects/node/napi-demo/build'
  CC(target) Release/obj.target/hello/hello.o
  SOLINK_MODULE(target) Release/hello.node
make: Leaving directory '/Users/tod/projects/node/napi-demo/build'
gyp info ok

added 29 packages, and audited 30 packages in 1s

4 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

$ npm run test

> [email protected] test
> node hello.js

world

$ npm run prebuild-darwin

> [email protected] prebuild-darwin
> prebuildify --napi --arch x64+arm64

gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | darwin | arm64
gyp info find Python using Python version 3.9.8 found at "/opt/homebrew/opt/[email protected]/bin/python3.9"
gyp info spawn /opt/homebrew/opt/[email protected]/bin/python3.9
gyp info spawn args [
gyp info spawn args   '/Users/tod/.nvm/versions/node/v17.1.0/lib/node_modules/npm/node_modules/node-gyp/gyp/gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'make',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/tod/projects/node/napi-demo/build/config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/tod/.nvm/versions/node/v17.1.0/lib/node_modules/npm/node_modules/node-gyp/addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/var/folders/s3/2m6c75n08xj65_0059bmnvk00000gp/T/prebuildify/node/17.0.0/include/node/common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=/var/folders/s3/2m6c75n08xj65_0059bmnvk00000gp/T/prebuildify/node/17.0.0',
gyp info spawn args   '-Dnode_gyp_dir=/Users/tod/.nvm/versions/node/v17.1.0/lib/node_modules/npm/node_modules/node-gyp',
gyp info spawn args   '-Dnode_lib_file=/var/folders/s3/2m6c75n08xj65_0059bmnvk00000gp/T/prebuildify/node/17.0.0/<(target_arch)/node.lib',
gyp info spawn args   '-Dmodule_root_dir=/Users/tod/projects/node/napi-demo',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'build',
gyp info spawn args   '-Goutput_dir=.'
gyp info spawn args ]
gyp info spawn make
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
make: Entering directory '/Users/tod/projects/node/napi-demo/build'
  CC(target) Release/obj.target/hello/hello.o
  SOLINK_MODULE(target) Release/hello.node
make: Leaving directory '/Users/tod/projects/node/napi-demo/build'
gyp info ok

$ ls
README.md          build/             hello.js           node_modules/      package.json
binding.gyp        hello.c            helloworld.c       package-lock.json  prebuilds/

$ rm -rf build
$ npm run test

> [email protected] test
> node hello.js

node:internal/modules/cjs/loader:1179
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: dlopen(/Users/tod/projects/node/napi-demo/prebuilds/darwin-x64+arm64/node.napi.node, 0x0001): tried: '/Users/tod/projects/node/napi-demo/prebuilds/darwin-x64+arm64/node.napi.node' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')), '/usr/local/lib/node.napi.node' (no such file), '/usr/lib/node.napi.node' (no such file)
    at Object.Module._extensions..node (node:internal/modules/cjs/loader:1179:18)
    at Module.load (node:internal/modules/cjs/loader:975:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:999:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at load (/Users/tod/projects/node/napi-demo/node_modules/node-gyp-build/index.js:21:10)
    at Object.<anonymous> (/Users/tod/projects/node/napi-demo/hello.js:4:40)
    at Module._compile (node:internal/modules/cjs/loader:1097:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1149:10)
    at Module.load (node:internal/modules/cjs/loader:975:32) {
  code: 'ERR_DLOPEN_FAILED'
}

Node.js v17.1.0

$ file prebuilds/darwin-x64+arm64/node.napi.node
prebuilds/darwin-x64+arm64/node.napi.node: Mach-O 64-bit bundle x86_64

$ arch -x86_64 /bin/bash -c "source $HOME/.nvm/nvm.sh; nvm install 17.0.1" &&  nvm use 17.0.1
v17.0.1 is already installed.
Now using node v17.0.1 (npm v8.1.0)
Now using node v17.0.1 (npm v8.1.0)
$ node -p process.arch
x64
$ npm run test

> [email protected] test
> node hello.js

world

Include dirs for N-API messed up

I think this utility is messing up include directories. Building a N-API module yields the following issue:

/home/rsa/js/node-argon2/node_modules/node-addon-api/napi.h:4:10: fatal error: node_api.h: No such file or directory
 #include "node_api.h"
          ^~~~~~~~~~~~

The same problem does not happen with node-gyp rebuild.

Relevant bindings.gyp entries:

"sources": [
  "src/argon2_node.cpp"
],
"include_dirs": ["<!@(node -p \"require('node-addon-api').include\")"],

I am unsure how to debug further since prebuildify does not expose node-gyp verbose flag, and I can't see the compiler command line.

Investigate test failure on node 8

https://travis-ci.org/github/prebuild/prebuildify/jobs/681902103
https://travis-ci.org/github/prebuild/prebuildify/jobs/681901064

# prefers locally installed node-gyp bin
C:\Users\travis\build\prebuild\prebuildify\test\mock-gyp>if not defined npm_config_node_gyp (node "C:\ProgramData\nvs\node\8.17.0\x64\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild --target=v8.17.0 --devdir=C:\Users\travis\AppData\Local\Temp\prebuildify\node --target_arch=x64 --release )  else (node "C:\ProgramData\nvs\node\8.17.0\x64\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" rebuild --target=v8.17.0 --devdir=C:\Users\travis\AppData\Local\Temp\prebuildify\node --target_arch=x64 --release ) 
not ok 7 should be equal
  ---
    operator: equal
    expected: |-
      'node-gyp exited with 123'
    actual: |-
      'node-gyp exited with 1'
    at: ChildProcess.<anonymous> (C:\Users\travis\build\prebuild\prebuildify\index.js:209:24)
    stack: |-
      Error: should be equal
          at Test.assert [as _assert] (C:\Users\travis\build\prebuild\prebuildify\node_modules\tape\lib\test.js:228:54)
          at Test.bound [as _assert] (C:\Users\travis\build\prebuild\prebuildify\node_modules\tape\lib\test.js:80:32)
          at Test.equal (C:\Users\travis\build\prebuild\prebuildify\node_modules\tape\lib\test.js:389:10)
          at Test.bound [as is] (C:\Users\travis\build\prebuild\prebuildify\node_modules\tape\lib\test.js:80:32)
          at C:\Users\travis\build\prebuild\prebuildify\test\api.js:52:7
          at C:\Users\travis\build\prebuild\prebuildify\index.js:70:23
          at C:\Users\travis\build\prebuild\prebuildify\index.js:86:23
          at ChildProcess.<anonymous> (C:\Users\travis\build\prebuild\prebuildify\index.js:209:24)
          at emitTwo (events.js:126:13)
          at ChildProcess.emit (events.js:214:7)

How to use multiple .node files?

Hi, I'm the current maintainer of node-hid. It supports two different back-end native libraries on Linux: libusb or hidraw. The bindings loading currently looks like:

            if( !driverType || driverType === 'hidraw' ) {
                binding = require('bindings')('HID_hidraw.node');
            } else {
                binding = require('bindings')('HID.node');
            }
        }

How do I accomplish something similar using prebuildify and node-gyp-build?

I have a test repo that generates two simple .node libraries here: https://github.com/todbot/napi-demo
I can see that node-gyp is correctly building both:

$ ls -1 build/Release/*node
build/Release/hello1.node*
build/Release/hello2.node*

but prebuildify is only taking hello1.node and renaming it to node.napi.node, leaving hello2.node behind. And I don't see now in node-gyp-build I can specify which .node.

Cmake-js support

prebuild supports cmake-js, but prebuildify does not. It would be good if they both are able to work with cmake-js.

Update prebuild naming to scheme

With the added metadata from various PRs plus my personal intent to add stuff like the libuv major version to the name for prebuilds that use that (to ensure abi compatibility) I've been thinking we should make our naming a bit more generic.

Here are my thoughts.

Currently our prebuild names look like this: {runtime}-{napi|abi}.node

I suggest we move to something a bit more explicit like this: {runtime}-{name(.value)?}-{name(.value)?}....node

For example for a napi build for node that tags the uv major version 1: node-napi-uv.1.node
Or one that tags a special libc for abi 40: node-abi.40-libc.musl.node or to tag alpine as the os, node-abi.40-os.alpine.node

The prebuild picker, node-gyp-build would then pick the one with the most tags that match (obvs abi or napi must match first etc).

WDYT? The use of . and - as separators is somewhat arbitrary and I'm open for suggestions

gyp: name 'build_v8_with_gn' is not defined

I'm seeing this occasional error while trying to prebuildify:

gyp: name 'build_v8_with_gn' is not defined while evaluating condition 'build_v8_with_gn == "true"' in binding.gyp while trying to load binding.gyp

It only shows up sometimes, though I can reproduce it reliably using a clean checkout of turbo-net. Full stack below:

sephsmac:turbo-net josephg$ prebuildify --napi
gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | darwin | x64
gyp info spawn /usr/bin/python
gyp info spawn args [ '/Users/josephg/.nvm/versions/node/v9.11.1/lib/node_modules/node-gyp/gyp/gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'make',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/josephg/3rdparty/turbo-net/build/config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/josephg/.nvm/versions/node/v9.11.1/lib/node_modules/node-gyp/addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/Users/josephg/.node-gyp/10.0.0/include/node/common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=/Users/josephg/.node-gyp/10.0.0',
gyp info spawn args   '-Dnode_gyp_dir=/Users/josephg/.nvm/versions/node/v9.11.1/lib/node_modules/node-gyp',
gyp info spawn args   '-Dnode_lib_file=/Users/josephg/.node-gyp/10.0.0/<(target_arch)/node.lib',
gyp info spawn args   '-Dmodule_root_dir=/Users/josephg/3rdparty/turbo-net',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'build',
gyp info spawn args   '-Goutput_dir=.' ]
gyp: name 'build_v8_with_gn' is not defined while evaluating condition 'build_v8_with_gn == "true"' in binding.gyp while trying to load binding.gyp
gyp ERR! configure error 
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/Users/josephg/.nvm/versions/node/v9.11.1/lib/node_modules/node-gyp/lib/configure.js:336:16)
gyp ERR! stack     at ChildProcess.emit (events.js:180:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:12)
gyp ERR! System Darwin 17.5.0
gyp ERR! command "/Users/josephg/.nvm/versions/node/v9.11.1/bin/node" "/Users/josephg/.nvm/versions/node/v9.11.1/bin/node-gyp" "rebuild" "--target=10.0.0" "--target_arch=x64" "--release"
gyp ERR! cwd /Users/josephg/3rdparty/turbo-net
gyp ERR! node -v v9.11.1
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok 
node-gyp exited with 1

The specified module could not be found

I'm attempting to upgrade my app from Electron v3 to v7. macOS and Linux works fine, but I'm getting the following errors on Windows:

32-bit:

Uncaught Error: The specified module could not be found.
\\?\C:\Program Files\Tidepool Uploader\resources\app.asar.unpacked\node_modules\lzo-decompress\prebuilds\win32-ia32\electron.napi.node

64-bit:

Uncaught Error: The specified module could not be found.
\\?\C:\Program Files\Tidepool Uploader\resources\app.asar.unpacked\node_modules\lzo-decompress\prebuilds\win32-x64\electron.napi.node

I've found some threads relating to that error appearing when some .dll's cannot be found. I'm still using the same .dll's that worked under Electron v3, so I thought it may be due to https://electronjs.org/docs/tutorial/using-native-node-modules#a-note-about-win_delay_load_hook, but my understanding is that win_delay_load_hook is handled by node-gyp-build?

The module's source code can be found here: https://github.com/tidepool-org/lzo-decompress/tree/update-deps

Notes:

  • I've updated to the latest versions of prebuildify, node-gyp-build and napi-macros.
  • I'm using prebuildify --napi and prebuildify --arch=ia32 --napi to generate the prebuilds
  • Obviously the .node files in question are actually there

[Question] specify napi version

Apologies if I've missed some docs somewhere, but it isn't clear how to specify the napi version when using the --napi flag.

I assumed the target flag would be used, e.g. --napi --target 4 similar to prebuild, but this results in an error:

TypeError: v.indexOf is not a function

It seems you need to find the earliest corresponding node version for the napi version you want instead from the Node-API Version Matrix, is that right?

So for napi 4 you specify --napi --target 10.16.0

Finally, is the default napi version used the latest available rather than the oldest. I'm keen to promote interoperability by building for the oldest Node API?

Cheers!

Standardized way of publishing debug files

Hi,
I'm currently fighting a few crashes in my electron app related to native modules. Since the stack traces generated by minidump are not very helpful without the debug files generated at build time of the modules, we're having trouble figuring out what the problem is, for example here and here.

If the build pipeline could download the debug files generated by prebuildify (for example .pdb on Windows) and upload it to the Crash Reporting Service (in my case Sentry), it would allow for much easier debugging.

How could this be achieved in a standardized way, so that people don't have to write a separate download script for the debug files of each package?

I don't think it's a good idea to include those files in the publish tarball (for npm for example), because they can be quite big and are (as far as I know) not needed in the application itself but rather for the crash reporting service on the serverside.

Naming of fat binaries for M1 (Apple silicon)

In order to support M1 (Apple silicon), addon authors can build so-called fat binaries, that work on both x86_64 and arm64. This seems like the easiest way to add M1 support. For example fsevents/fsevents#350.

It's at odds with our current folder structure though. What would the arch be in e.g. darwin-<arch>/node.napi.node?

Cross compilation

I'm trying to implement prebuildify for node-serialport I have a hunch it would save us 50% of our support requests. I've wanted this package for years. This is a fantastic thing for you to make ❤️

I'd like to figure out how to publish every arch (linux, mac and windows) in a single package. Do you have any tips on cross compilation?

Can prebuildify publish executable?

{
    "targets": [
        {
            "target_name": "foo",
            "type": "executable",
        }
    ]
}

Will

Could not find build

. Currently only method is

{
    "targets": [
        {
            "target_name": "foo.node",
            "type": "executable",
        }
    ]
}

How can we package executable by prebuildify?

Prefer locally-installed node-gyp

Currently, prebuildify uses the node-gyp that's available in PATH and when npm runs scripts, it adds the global node_modules/npm-lifecycle/node-gyp-bin folder to PATH. Effectively, we're always using the npm-bundled version of node-gyp.

Sane defaults for js api?

We're using the js api of prebuildify which means we must mimic parts of what the cli does, e.g. doing:

function build () {
  function onlyNode (t) {
    return t.runtime === 'node'
  }

  function onlyElectron (t) {
    return t.runtime === 'electron'
  }

  const targets = [
    abi.supportedTargets.filter(onlyNode).pop(),
    abi.supportedTargets.filter(onlyElectron).pop()
  ]

  const opts = {
    quiet: false,
    strip: true,
    napi: true,
    targets,
    cwd: path.resolve(__dirname, '..')
  }

  prebuildify(opts, err => {
    if (err) exit(err)
    bundle()
  })
}

Any chance we could move the .napi and .all code into the prebuildify function? This would simplify to:

function build () {
  const opts = {
    quiet: false,
    strip: true,
    napi: true,
    cwd: path.resolve(__dirname, '..')
  }

  prebuildify(opts, err => {
    if (err) exit(err)
    bundle()
  })
}

Discussion about performance

This is about documentation not a bug.

It is claimed that a bundle with binaries for multiple platforms is faster than an install script for a single platform.
This is reasonable for small modules, but not for large modules, do you have any benchmark data that you could share, it would be interesting to point this in the README for future readers. If not I would be happy to help in this evaluation.

Thank you

Deleting unwanted prebuilds for Yocto

This is kind of a follow on to this: #54

We use a package (msgpackr-extract) that relies on prebuildify to do it's prebuilding.

The problem we have is that prebuildify leaves the various prebuilt binaries on the OS, even the ones that cannot possibly run (like 64 bit ones on a 32 bit system).

This is obviously normally not a problem, except for when you try and use it with a system like Yocto to build an OS.

Yocto has various QA systems and uses objcopy to move the binaries across. It blows up when you try and copy a 64 bit binary to a 32 bit OS because it knows it could never possibly run.

My current solution is rm -rf node_modules/msgpackr-extract/prebuilds after npm install has finished, to wipe out all the prebuilt binaries (the one we need isn't shipped anyway).
Obviously, this is a bit of an ugly hack.

Is there any way that this situation could be handled differently to make it more compatible with build systems?

Prebuilds cannot be found with node-gyp-build

Prebuild is building the library here::

$ ls prebuilds/foundationdb-v0.4.0-node-v*
...
prebuilds/foundationdb-v0.4.0-node-v51-darwin-x64.tar.gz
prebuilds/foundationdb-v0.4.0-node-v57-darwin-x64.tar.gz
prebuilds/foundationdb-v0.4.0-node-v59-darwin-x64.tar.gz

But node-gyp-build is looking in these directories for binaries:

getFirst build/Release
getFirst build/Debug
getFirst prebuilds/darwin-x64
getFirst prebuilds/darwin-x64

... And then not finding the library.

I'm using [email protected] and [email protected]

Distributing N-API modules for different linux distributions

Hi,

I'm using an npm package that is built using this project, and run into this issue which I'm trying to fix.

The problem is that the package is built and linked with glibc, and some users are trying to run it on Alpine, which uses the musl libc. I understand that this combination is not meant to work, and wonder what's your recommended way for dealing with this.

I have a few options in mind:

  1. Link the libc statically for Linux distributions.
  2. Have separate prebuilds for glibc- and musllibc-based systems.
  3. Fallback to a js implementation in musllibc-based systems.

I'd say that my personal preference would be (1), but I'd love to know your opinions. I'm not exactly sure how any option would be implemented.

Can you please help me with this?

Thanks!

Keeps using Node 5.0.0 headers [win64]

This is essentially the same issue as #28.
The proposed fix, which is simply deleting the ~\.node-gyp folder and trying to re-build afterwards, doesn't work for me though.

I'm trying to build including the NAPI header files with the following command

prebuildify --stip --all --napi

which works perfectly fine on macOS. However, on Windows I get the following exception:

fatal error C1083: Cannot open include file: 'node_api.h': No such file or dire
ctory (compiling source file ..\src\main.cc) [C:\Users\pahmeyer\Documents\node-gdx\build\node-gdx.vcxproj]

When I check the console output, I see that it keeps downloading header files for Node 5.0.0, which didn't include the NAPI yet.

gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | win32 | x64
gyp http GET https://nodejs.org/dist/v5.0.0/node-v5.0.0-headers.tar.gz
gyp http 200 https://nodejs.org/dist/v5.0.0/node-v5.0.0-headers.tar.gz
gyp http GET https://nodejs.org/dist/v5.0.0/SHASUMS256.txt
gyp http GET https://nodejs.org/dist/v5.0.0/win-x86/node.lib
gyp http GET https://nodejs.org/dist/v5.0.0/win-x64/node.lib
gyp http 200 https://nodejs.org/dist/v5.0.0/win-x64/node.lib
gyp http 200 https://nodejs.org/dist/v5.0.0/win-x86/node.lib
gyp http 200 https://nodejs.org/dist/v5.0.0/SHASUMS256.txt

Checking

node -p process.release

points to the correct header url.

{ name: 'node',
  lts: 'Dubnium',
  sourceUrl:
   'https://nodejs.org/download/release/v10.15.0/node-v10.15.0.tar.gz',
  headersUrl:
   'https://nodejs.org/download/release/v10.15.0/node-v10.15.0-headers.tar.gz',
  libUrl:
   'https://nodejs.org/download/release/v10.15.0/win-x64/node.lib' }

Does anyone have an idea of how this can be fixed?
Thanks in advance!

gyp: name 'openssl_fips' is not defined while evaluating condition 'openssl_fips != ""' in node_modules/node-addon-api/node_api.gyp while loading dependencies of binding.gyp while trying to load binding.gyp

  • node -v: v18.9.0
  • node-gyp --version: v9.1.0
  • prebuilfidy -- ^5.0.1
    Hi, I'm trying to use prebuildify in my project: https://github.com/vaguue/net-runner-engine. Now only linux-x64 is supported. When I run prebuildify --target v18.9.0 everything seems to be fine, however, when I run prebuildify --all I get this error:
    gyp: name 'openssl_fips' is not defined while evaluating condition 'openssl_fips != ""' in node_modules/node-addon-api/node_api.gyp while loading dependencies of binding.gyp while trying to load binding.gyp
    Thanks in advance!

Builds fail on Node 12 and earlier because Node 14's binding.gyp is incompatible

prebuildify seems to always uses the latest headers, but the included gyp config file for Node 14 is incompatible with Node 12 and earlier because include/node/common.gypi checks the value of v8_enable_pointer_compression which only exists in Node 13+.

$ prebuildify --napi --strip --tag-libc
gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | darwin | x64
gyp info find Python using Python version 2.7.10 found at "/usr/bin/python"
gyp info spawn /usr/bin/python
gyp info spawn args [
gyp info spawn args   '/usr/local/Cellar/node@12/12.16.2_1/lib/node_modules/npm/node_modules/node-gyp/gyp/gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'make',
gyp info spawn args   '-I',
gyp info spawn args   '.../source-map/build/config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/usr/local/Cellar/node@12/12.16.2_1/lib/node_modules/npm/node_modules/node-gyp/addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/var/folders/sr/6fx9jkvn2574qm892qch3wq00000gn/T/prebuildify/node/14.0.0/include/node/common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=/var/folders/sr/6fx9jkvn2574qm892qch3wq00000gn/T/prebuildify/node/14.0.0',
gyp info spawn args   '-Dnode_gyp_dir=/usr/local/Cellar/node@12/12.16.2_1/lib/node_modules/npm/node_modules/node-gyp',
gyp info spawn args   '-Dnode_lib_file=/var/folders/sr/6fx9jkvn2574qm892qch3wq00000gn/T/prebuildify/node/14.0.0/<(target_arch)/node.lib',
gyp info spawn args   '-Dmodule_root_dir=.../source-map',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'build',
gyp info spawn args   '-Goutput_dir=.'
gyp info spawn args ]
gyp: name 'v8_enable_pointer_compression' is not defined while evaluating condition 'v8_enable_pointer_compression == 1' in binding.gyp while trying to load binding.gyp
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/usr/local/Cellar/node@12/12.16.2_1/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:351:16)
gyp ERR! stack     at ChildProcess.emit (events.js:310:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
gyp ERR! System Darwin 17.7.0
gyp ERR! command "/usr/local/Cellar/node@12/12.16.2_1/bin/node" "/usr/local/Cellar/node@12/12.16.2_1/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--target=14.0.0" "--devdir=/var/folders/sr/6fx9jkvn2574qm892qch3wq00000gn/T/prebuildify/node" "--target_arch=x64" "--release"
gyp ERR! cwd .../source-map
gyp ERR! node -v v12.16.2
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.