Repository navigation
Implement napi_module_register #70
Description
Activity
- added a parent issue
on May 14, 2025 - added a commit that references this issue
on May 21, 2025 - added a commit that references this issue
on Jun 12, 2025 - added a commit that references this issue
on Jun 20, 2025 - linked a pull request that will close this issueRefactor C++ loader: extract cache and addon registry, resolve TODOs #104
on Jul 12, 2025 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_registerby stashing the module in a process-global (API/napi/hermes_napi.cpp), to be read back viahermes_napi_get_last_registered_module(). Hermes' own loader (hermes_napi_load_module) consults it whennapi_register_module_v1is missing.Our host does not use that loader:
CxxNodeApiHostModule::loadNodeAddondlopen's the addon itself and looks upnapi_register_module_v1by symbol, and when it's absent it logs "Expecting the addon to callnapi_module_registerto register itself" and returnsfalse— sorequireNodeAddonreturnsundefined. 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 thenapi_register_module_v1lookup fails, fall back tohermes_napi_get_last_registered_module()and use itsnm_register_func. Worth deciding first whether we want to support the deprecated path at all —NAPI_MODULE_INIT/napi_register_module_v1has been the recommended entry point for a long time, and closing this as "not planned" is a legitimate outcome too.
Generated by Claude Code