You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The README.md for prebuild-install suggest migrating to prebuildify where, instead of publishing native binaries to the GitHub release, they are instead added to the prebuilds/ directory and published inside the package itself.
I have done this on my private fork, because it was easier to get working than figuring out how to access a private repo's GitHub releases. Benefits include (1) less dependence on GitHub releases, (2) potentially faster install times, and (3) no need for install scripts. However, it would mean slightly larger NPM packages and a different release process.
Steps I took…
Change the ci:prebuild script in package.json:
"ci:prebuild": "prebuildify --runtime napi --target 16.0.0 --strip --verbose",
Remove the install script from package.json. Alternatively, it could be kept and set to node-gyp-build, per the prebuildify docs; however, that would require publishing the binding.gyp and other files that are not currently published in order for it to work. In my case, the machine that installs @pg-nano/pg-parser isn't going to have the tools to build it from source anyway, so I skip this step.
Update dependencies in package.json. bindings, prebuild, and prebuild-install can be removed. node-gyp-build can be added as a dependency, and prebuildify can be added as a dev dependency.
Update files in package.json to include the prebuilds/ directory.
Change src/lib/binding.ts. The README.md for prebuildify suggests using node-gyp-build to load the addon. Depending on whether feat: dual-publish ESM and CJS #8 is accepted, the "isomorphic __dirname" trick can be used to get the correct path in both CJS and ESM:
The
README.md
forprebuild-install
suggest migrating toprebuildify
where, instead of publishing native binaries to the GitHub release, they are instead added to theprebuilds/
directory and published inside the package itself.I have done this on my private fork, because it was easier to get working than figuring out how to access a private repo's GitHub releases. Benefits include (1) less dependence on GitHub releases, (2) potentially faster install times, and (3) no need for
install
scripts. However, it would mean slightly larger NPM packages and a different release process.Steps I took…
Change the
ci:prebuild
script inpackage.json
:Remove the
install
script frompackage.json
. Alternatively, it could be kept and set tonode-gyp-build
, per theprebuildify
docs; however, that would require publishing thebinding.gyp
and other files that are not currently published in order for it to work. In my case, the machine that installs@pg-nano/pg-parser
isn't going to have the tools to build it from source anyway, so I skip this step.Update dependencies in
package.json
.bindings
,prebuild
, andprebuild-install
can be removed.node-gyp-build
can be added as a dependency, andprebuildify
can be added as a dev dependency.Update
files
inpackage.json
to include theprebuilds/
directory.Change
src/lib/binding.ts
. TheREADME.md
forprebuildify
suggests usingnode-gyp-build
to load the addon. Depending on whether feat: dual-publish ESM and CJS #8 is accepted, the "isomorphic__dirname
" trick can be used to get the correct path in both CJS and ESM:Additionally, when building on macOS, I use the following script and Dockerfiles to build for Linux before publishing:
The text was updated successfully, but these errors were encountered: