nw-builder Packages NW.js Apps for Three Desktop Platforms

nw-builder Addresses NW.js Desktop Distribution

nw-builder addresses the problem of turning an application built around the NW.js runtime into desktop packages for Linux, macOS, and Windows. It is intended for developers working with NW.js applications who need repeatable build and packaging operations. It is not presented as a general installer builder for unrelated frameworks.

The repository is more than a single package. Its root README lists `nw-builder` and `@nwutils/builder` as tools that build NW.js desktop applications. It also identifies `@nwutils/cli` as a command-line interface for building those applications. This naming can make the project appear to offer several competing builders when the repository actually presents a collection of related packages with different responsibilities.

That distinction matters during dependency selection. The root README does not say whether the original `nw-builder` package is a compatibility layer, a separate API, or a predecessor of `@nwutils/builder`. It also does not document migration between them. A developer deciding which package to install must inspect the relevant directory under `packages/` and consult that package's own documentation rather than relying on the root package list.

The Monorepo Divides Build Work by Function

Based on the repository layout and the package descriptions in the README, NW.js tooling is divided by function. `@nwutils/getter` retrieves NW.js and related binaries for Linux, macOS, and Windows. `@nwutils/packager` packages NW.js and related binaries for those platforms. `@nwutils/runner` runs NW.js and related binaries, while `@nwutils/doctor` configures NW.js environments.

This division covers several stages that an NW.js project may need. An application workflow can require obtaining the correct runtime, preparing the environment, running the project, and packaging the result. `@nwutils/builder` is described as the build-level package, and `@nwutils/cli` provides a command-line interface for building applications. The README does not expose the internal call graph, so the exact sequence and data passed between these packages cannot be confirmed from the root documentation.

The repository uses npm workspaces. Its root `package.json` lists `packages/*` under `workspaces`, which means the packages are managed within one JavaScript repository. This arrangement supports coordinated changes across related tools, but it also makes package boundaries important. The root README does not publish a compatibility matrix for the scoped packages, so selecting one version of each dependency requires checking the individual package manifests.

Repository Development Begins With npm Workspaces

The root README documents development of the monorepo rather than installation of `nw-builder` inside an existing NW.js application. The first documented step installs repository dependencies:

npm install

This command installs the dependencies needed to work on `nwutils/nw-builder`. It is not a documented consumer setup command for a new NW.js application, and the README does not explain which published package or version an application should depend on.

The next documented check runs lint tasks across workspaces:

npm run lint

The root script is `npm run lint --workspaces --if-present`. It delegates the command to each workspace that defines a lint script and skips workspaces that do not. After installation, a developer can use this repository-level check to inspect the lint configuration across all packages.

The README also gives a separate type-checking command:

npm run type

The root manifest delegates this command to workspaces with a type script. The README does not state whether this validates public type declarations, internal JavaScript, or generated content. It is therefore safe to describe the command as the repository's documented type-check step, but not to infer more detailed coverage.

Tests Run Across or Within One Workspace

The documented repository test command is:

npm test

The root script runs `npm run test --workspaces --if-present`, so it delegates testing to every workspace that defines a test script. The README explicitly states that the root commands fan out across every package in `./packages`.

Contributors can narrow the documented example to one workspace:

npm test --workspace=@nwutils/getter

This form runs the getter workspace's test script instead of starting from the entire monorepo. It is the clearest executable example of package-level work in the README. The command does not tell a user how to build an application, retrieve a runtime for a new project, or configure a packaging target.

Formatting has a distinct root-level script. The manifest defines `npm run format` as `prettier --check .`, so the documented validation command is:

npm run format

The repository also defines `format:fix` as `prettier --write .`, but the README does not use that command in its development instructions. The README does not provide expected output from the test suite, coverage figures, or platform-specific test results, so it would be misleading to promise any particular result from these commands.

Three Target Platforms Leave Packaging Questions Open

The stated support for Linux, macOS, and Windows gives `nwutils/nw-builder` a clear cross-platform scope. It does not answer how a production package is configured for each operating system. The root README does not document application bundle naming, executable permissions, icon selection, installer formats, code signing, notarization, or native dependency handling.

Those omissions are particularly important for desktop distribution. A build that creates an application directory is not necessarily a complete Linux package, a signed macOS distribution, or an installable Windows artifact. The README's package descriptions establish intended platform scope, but they do not define the exact output or release requirements for each target.

The repository also claims support for update-related work, yet the root README does not explain what “update” means in this context. It gives no command for changing an NW.js version, applying an update to an existing build, or rolling back to a previous application package. The update function should therefore remain a product capability claimed by the README, not a documented operational procedure.

The available commands are repository maintenance checks. They do not demonstrate a consumer build, an installer, or a signed release. Anyone requiring those outcomes must locate the documentation for `@nwutils/builder`, `@nwutils/packager`, or `@nwutils/cli` before considering the workflow complete.

Node Configuration Describes the Monorepo Environment

The root `package.json` uses `"type": "module"` and declares development engines for Node.js 26.7.0 and npm 12.0.2. Both engine entries use `onFail: "warn"`, so the manifest permits a warning when those versions are not present. This configuration belongs to the root development environment. The README does not state that Node.js 26.7.0 or npm 12.0.2 are minimum requirements for applications built with every published package.

The root manifest also contains development dependencies for NW.js, TypeScript, ESLint, Prettier, Selenium WebDriver, and supporting type packages. These dependencies support repository development and testing. Their presence does not mean every application generated by `nw-builder` will include them in its packaged output.

The repository uses `tsconfig.json`, `eslint.config.js`, and a root `package-lock.json`. That structure indicates a JavaScript monorepo with explicit linting, formatting, and type-checking configuration. The README does not explain the compilation boundary for the packages or state how source files are distributed through npm, so the publication layout remains unspecified.

Recent Releases Do Not Replace Compatibility Checks

The repository is not archived, and its last push was on 2026-10-16. Recent releases include `nw-builder-v4.21.4`, published on 2026-10-03, `nw-builder-v4.21.3`, also published on 2026-10-03, and `nw-builder-v4.21.2`, also published on 2026-10-03. The sequence shows recent release activity, but the release information does not state what changed or whether consumers must update related workspace packages.

The root project uses the MIT license, which is also declared in its `package.json`. The repository includes an MIT `LICENSE` file. An application may receive additional licensing considerations from NW.js binaries or other bundled dependencies, but their licensing terms are not discussed in the root README. The repository documentation therefore supports confirming the MIT declaration while leaving third-party artifact review as a separate task.

No migration guide or rollback instructions for the `v4.21.x` releases appear in the README. An upgrade assessment should begin with the release documentation for the exact package placed in an application's dependency graph. Until that package states its compatibility requirements, recent publication dates alone cannot establish that an existing NW.js build will migrate without configuration changes.

Editorial conclusion

Adopt nw-builder when you need NW.js-specific packaging for several desktop operating systems and can consult the documentation for the individual package you will use. Do not choose it from the root repository alone if you need a documented first-build workflow, signing process, or rollback procedure. Before adoption, verify the target package README, its required NW.js version, its binary download behavior, and its platform-specific packaging options. The last concrete choice is whether the package configuration covers your application sources, output expectations, and release process.

Frequently asked questions

Official sources

1. License: MIT
2. nwutils/nw-builder on GitHub
3. Project website
4. README
5. Releases