Skip to content

Improving DX of co-shipping Node.js prebuilds #145

@kraenhansen

Description

@kraenhansen

Library authors might want to publish packages containing prebuilds for Node.js alongside the React Native specific prebuilds, if they have a use-case for targeting Node.js or wants to make it easier for app developers to test without having to mock the native addon of the library.

Library authors can use cmake-js, node-gyp (if they use CMake or GYP respectively) to build for Node.js.

Annoyance #1: Prebuild / output location

By default, both cmake-js and node-gyp output the dynamic library produced when building to ${projectRoot}/build/${configuration}/${targetName}.node.

☝ has the disadvantage that dynamic libraries compiled on different operating systems / architectures share the same path of disk.

Developers use tools like prebuild or prebuildify (supports only GYP), to build and structure multiple os+arch specific binaries.

The cmake-rn store its output platform-specific & arch-specific subdirectories of ${projectRoot} (see out PREBUILDS.md for details on the structure of these directories).

Note

${projectRoot} in the paths above is not the package root, but instead the directory containing the binding.gyp or CMakeLists.txt configurations of the particular build system.

Annoyance #2: Executing two commands

It's annoying to have to invoke multiple tools (which might have slightly different runtime options / args).

Ideally a library author should be able to just select the platforms / triplets they want to build for:

  • React Native (iOS / Android)
  • Node.js (Windows, Linux, MacOS)

To be more compatible with the existing tools for Node.js, we could:

  1. write our prebuilds into the ${projectRoot}/build/${configuration} directory, the same way cmake-js and node-gyp does.
  2. make it easier to build for Node.js
    1. by adding Node.js as a target for cmake-rn (feels wrong, as the -rn suffix).
    2. provide yet another CLI wrapping cmake-js and cmake-rn (feels a bit too abstracted).
    3. provide yet another CLI with direct support for multiple platforms / operating-systems, with a pluggable architecture to make it easier to add support for future out-of-tree platforms as well.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions