# neon-load-or-build

> Build tool and bindings loader for Neon that supports prebuilds

Latest version **2.2.2** (published 2020-10-19) · MIT license · 0 weekly downloads

## Install

```sh
npm install neon-load-or-build
pnpm add neon-load-or-build
yarn add neon-load-or-build
bun add neon-load-or-build
```

Provides the commands `neon-load-or-build`, `neon-load-or-build-test`, `neon-load-or-build-optional`.

## Health

**Score 15/100 (F)** — status: abandoned.

Positive: no vulnerabilities.

Warnings: low downloads; no types; no esm support.

Negative: abandoned; low maintenance score.

## Facts

| | |
|---|---|
| Version | 2.2.2 |
| Published | 2020-10-19 |
| First published | 2020-09-22 |
| Weekly downloads | 0 |
| License | MIT |
| TypeScript types | none |
| Module format | CommonJS |
| Dependencies | 0 |
| Unpacked size | 68.6 KB |
| Known vulnerabilities | 0 |
| Install scripts | no |
| Author | Andre Staltz |
| Maintainers | staltz |

## Links

- npm: https://www.npmjs.com/package/neon-load-or-build
- Repository: https://github.com/staltz/neon-load-or-build
- Issues: https://github.com/staltz/neon-load-or-build/issues
- npm.io page: https://npm.io/package/neon-load-or-build

## Recent versions

- 2.2.2 (latest) — 2020-10-19
- 2.2.1 — 2020-10-19
- 2.2.0 — 2020-10-16
- 2.1.0 — 2020-10-16
- 2.0.0 — 2020-10-16
- 1.1.0 — 2020-09-27
- 1.0.1 — 2020-09-24
- 1.0.0 — 2020-09-22

## README

# neon-load-or-build

> Build tool and bindings loader for [Neon Bindings](neon-bindings.com/) that supports prebuilds.

```
npm install neon-load-or-build
```

Heavily inspired on and based on [node-gyp-build](https://github.com/prebuild/node-gyp-build).

## Usage

`neon-load-or-build` as a the CLI works similar to `neon build` except that it will check if a build or prebuild is present before rebuilding your project.

It's main intended use is as an npm install script and bindings loader for native modules that bundle prebuilds (inspired by [`prebuildify`](https://github.com/prebuild/prebuildify)).

First add `neon-load-or-build` as an install script to your native neon-bindings project (let's assume it's called "my-package"):

```js
{
  "name": "my-package",
  ...
  "scripts": {
    "install": "neon-load-or-build"
  }
}
```

Then in your neon module's `lib/index.js`, instead of using the default `require('../native)`, use `node-load-or-build` to load your binding.

```js
module.exports = require('neon-load-or-build')({
  moduleName: 'my-package', // optional but recommended
  dir: __dirname + '/..',
})
```

**When targeting nodejs-mobile, you must have `moduleName`**, because it more accurately finds the correct path on both iOS and Android, even if you use `noderify` (or even if you don't).

If you do these two things and bundle prebuilds, your Neon module will work for most platforms without having to compile on install time AND will work in both node and electron without the need to recompile between usage.

Users can override `neon-load-or-build` and force compiling by doing `npm install --build-from-source`.

Prebuilds will be attempted loaded from `MODULE_PATH/prebuilds/...` and then next `EXEC_PATH/prebuilds/...`.

## Supported prebuild names

If so desired you can bundle more specific flavors, for example `musl` builds to support Alpine, or targeting a numbered ARM architecture version.

These prebuilds can be bundled in addition to generic prebuilds; `neon-load-or-build` will try to find the most specific flavor first. Prebuild filenames are composed of _tags_. The runtime tag takes precedence, as does an `abi` tag over `napi`. For more details on tags, please see [`prebuildify`][prebuildify].

Values for the `libc` and `armv` tags are auto-detected but can be overridden through the `LIBC` and `ARM_VERSION` environment variables, respectively.

## License

MIT

---
_Source: https://npm.io/package/neon-load-or-build · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._