Repository navigation
Support for import('./native.node') #55821
Description
Activity
The alternative is to rely on
processor have a more ergonomicprocess.getNativeModule('./mode.node'), but I think users would prefer the ergonomics of a direct import.That would either load
./mode.nodeas a path relative to the CWD (a bit confusing coming fromrequire()), or would require passing a base URL (i.e.process.getNativeModule('./mode.node', import.meta.url))cc @nodejs/loaders
+1 for this. In my mind the only question is whether or not to require the type attribute; see #40541 (comment) and #40766. Are there any spec concerns with leaving it off? If we eventually support non-experimental
importof Wasm, will the attribute be required there? If so, it might seem odd that the attribute isn’t needed for.nodewhile it is needed for.wasmand.json(and other non-JavaScript types like.cssin browsers).Wasm was landed in HTML recently without requiring the
"type"attribute. So it's only needed for the "lesser capability" module formats of CSS and JSON.Reacted by Geoffrey BoothReacted by Jonas- added a commit that references this issue
on Dec 20, 2024 - added a commit that references this issue
on Jan 2, 2025 - added a commit that references this issue
on Sep 22, 2025
What is the problem this feature will solve?
Currently
requireneeds to be used in ES modules in order to be able to load native addons:Previous issue: #40541.
There is some discussion to be had around whether import assertions should be used for the type. Personally I would even prefer if the import assertion wasn't necessarily mandated like we do for Wasm imports.
What is the feature you are proposing to solve the problem?
Transparently add support for
import('./native.node')to work in the Node.js ESM implementation, based on the.nodefile extension.This is one of the few last features that
require()supports butimport()does not, and would help gain full parity between the module systems.What alternatives have you considered?
The alternative is to rely on
processor have a more ergonomicprocess.getNativeModule('./mode.node'), but I think users would prefer the ergonomics of a direct import.Some thought may need to be put to
defaultversus named exports support in this interface as well.