Skip to content

Implement napi_module_register #70

Description

@kraenhansen
No description provided.

Activity

  1. kraenhansen commented on Aug 12, 2026

    @kraenhansen
    CollaboratorAuthor

    Keeping this open while sweeping the rest of #56 — the symbol exists on next, but the legacy registration path it serves is not wired up end to end.

    Hermes' first-party Node-API (adopted in #372) implements napi_module_register by stashing the module in a process-global (API/napi/hermes_napi.cpp), to be read back via hermes_napi_get_last_registered_module(). Hermes' own loader (hermes_napi_load_module) consults it when napi_register_module_v1 is missing.

    Our host does not use that loader: CxxNodeApiHostModule::loadNodeAddon dlopen's the addon itself and looks up napi_register_module_v1 by symbol, and when it's absent it logs "Expecting the addon to call napi_module_register to register itself" and returns false — so requireNodeAddon returns undefined. An addon registering through the deprecated static-constructor path therefore still fails to load; nothing reads back the module Hermes recorded.

    Finishing this is a small change in packages/host/cpp/CxxNodeApiHostModule.cpp: after the napi_register_module_v1 lookup fails, fall back to hermes_napi_get_last_registered_module() and use its nm_register_func. Worth deciding first whether we want to support the deprecated path at all — NAPI_MODULE_INIT / napi_register_module_v1 has been the recommended entry point for a long time, and closing this as "not planned" is a legitimate outcome too.


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions