Can not import .node file in esm #40541

Activity

1. Mesteery

   added

   esmIssues and PRs related to the ECMAScript Modules implementation.Issues and PRs related to the ECMAScript Modules implementation.

   on Oct 21, 2021
2. iam-frankqiu commented on Oct 21, 2021

   

   iam-frankqiu

   on Oct 21, 2021

   Contributor

   More actions

   Maybe you should try setting the command-line options --experimental-specifier-resolution = node. The .node extension that isn't supported default has been a legacy extension. you should add the above options to support this extension.
3. Brooooooklyn commented on Oct 21, 2021

   

   Brooooooklyn

   on Oct 21, 2021

   Author

   More actions

   Should we default support .node file?
4. iam-frankqiu commented on Oct 21, 2021

   

   iam-frankqiu

   on Oct 21, 2021

   Contributor

   More actions

   Should we default support .node file?

   I don't think it's a good idea. actually. I even don't think .mjs should support default. I like the design of simple and easy to use.
5. iam-frankqiu

   closed this as completedon Oct 21, 2021
6. Brooooooklyn commented on Oct 21, 2021

   

   Brooooooklyn

   on Oct 21, 2021

   Author

   More actions

   What's the recommend way to deliver native addon as esm package?
7. Brooooooklyn commented on Oct 21, 2021

   

   Brooooooklyn

   on Oct 21, 2021

   Author

   More actions

   I need to wrap some annoying codes to make my package could be imported in esm:

   const { func1, func2, func3, func4 } = require('./some-addon.node')
   
   module.exports = {
     func1,
     func2,
     func3,
     func4,
   }

   👍React with 👍2Reacted by Romain Lamothe and nra
8. iam-frankqiu commented on Oct 21, 2021

   

   iam-frankqiu

   on Oct 21, 2021

   Contributor

   More actions

   https://nodejs.org/api/module.html#module_module_createrequire_filename
   Maybe it can help you to solve the puzzle.

   👍React with 👍1Reacted by yyjazsf
9. Brooooooklyn commented on Oct 21, 2021

   

   Brooooooklyn

   on Oct 21, 2021

   Author

   More actions

   Maybe it can help you to solve the puzzle.

   It doesn't help at all.
   It turns codes into:

   const { func1, func2, func3 } = createRequire(...)("./native.node")
   
   export { func1, func2, func3 }

   Please reopen this issue.
10. iam-frankqiu

    reopened this on Oct 22, 2021
11. Brooooooklyn commented on Oct 25, 2021

    

    Brooooooklyn

    on Oct 25, 2021

    Author

    More actions

    @mhdawson is this issue belong to Node-API scope?
12. mhdawson commented on Oct 25, 2021

    

    mhdawson

    on Oct 25, 2021

    Member

    More actions

    @Brooooooklyn I don't think this is specific to Node-API, more related to ESM. @nodejs/modules has there been discussion around the ESM plans for loading native modules?
13. bmeck commented on Oct 25, 2021

    

    bmeck

    on Oct 25, 2021

    Member

    More actions

    At some point in time it was ripped out and moved to

    node/lib/internal/modules/esm/get_format.js

    Line 26 in df22736

    const legacyExtensionFormatMap = {

    , I forget the exact reasoning but it partially dealt with not having a general MIME agreed upon / some push back since it would have people write code that didn't work in other environments / the introduction of createRequire.
14. GeoffreyBooth commented on Oct 25, 2021

    

    GeoffreyBooth

    on Oct 25, 2021

    Last edited by GeoffreyBooth

    Member

    More actions

    Supporting it via import is probably something we can’t do just yet until we wait and see how the spec settles with regard to JSON and WebAssembly imports. For now I think you should be able to do:

    import { createRequire } from 'module';
    const require = createRequire(import.meta.url);
    
    const nativeModule = require('./native.node');

    See https://nodejs.org/api/module.html#modulecreaterequirefilename
15. Brooooooklyn commented on Oct 25, 2021

    

    Brooooooklyn

    on Oct 25, 2021

    Last edited by Brooooooklyn

    Author

    More actions

    As I metioned below, createRequire usage is too verbose for library authors. For example if I had 10 functions exported from native addon and I want provide esm package for these functions, I need to write these codes:

    const { func1, func2, func3, func4, func5, func6, func7, func8, func9, func10 } = createRequire(...)("./native.node")
    
    export { func1, func2, func3, func4, func5, func6, func7, func8, func9, func10 }
16. 8 remaining items

    Load more

17. motla commented on Dec 20, 2021

    

    motla

    on Dec 20, 2021

    More actions

    As I metioned below, createRequire usage is too verbose for library authors. For example if I had 10 functions exported from native addon and I want provide esm package for these functions, I need to write these codes:

    const { func1, func2, func3, func4, func5, func6, func7, func8, func9, func10 } = createRequire(...)("./native.node")
    
    export { func1, func2, func3, func4, func5, func6, func7, func8, func9, func10 }

    ---

    @Brooooooklyn What about, in your module my-native-addon:

    main.mjs

    import { createRequire } from "module"
    export default createRequire(import.meta.url)("./native.node")

    ---

    Then in your application code

    import addon from "my-native-addon"
    console.log(addon.func1, addon.func2)

    or

    import { func1, func2 } from "my-native-addon"
    console.log(func1, func2)
18. Brooooooklyn commented on Dec 20, 2021

    

    Brooooooklyn

    on Dec 20, 2021

    Author

    More actions

    @motla I want my package to be compatible with CommonJS and esm. And I don't want to write two copies of index.js

    👍React with 👍3Reacted by Romain Lamothe, Daniel and Sergei Davidovich Kolmiller
19. CamJN

    added a commit that references this issue on Jan 15, 2023

    fix named exports

    ...

    ec7102e
20. Ashoat

    added a commit that references this issue on Feb 20, 2023

    [keyserver] Fix rust-node-addon after deprecation of --experimental-s…

    ...

    9acb9c0
21. JonasBa commented on Jun 16, 2023

    

    JonasBa

    on Jun 16, 2023

    Contributor

    More actions

    Something worth noting is that if you do go with the createRequire(import.meta.url), you might end up breaking bundling as the expression is no longer analyzable. The nice part about cjs is that once require is detected, most bundlers will have a way to copy the binary to your dist folder and change the import path, so everything just works.

    If you do decide to go via createRequire route, you risk bailing out of that detection and end up with either build errors or runtime errors (missing bindings as they were never moved to the correct path). As a library author, I would want to see .node file imports being directly supported without us requiring to add any global helpers that risk naming collision or subtly breaking out of the build process.

    👍React with 👍3Reacted by Joe Becher, Tim Fish and nra

    😕React with 😕1Reacted by Mario Valle
22. d3x0r commented on Aug 30, 2023

    

    d3x0r

    on Aug 30, 2023

    Contributor

    More actions

    How is not supporting .node in .mjs import making this 'easy to use' ?

    TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".node" for (fullpathto)\sack_vfs.node

    okay - fine I'll use require....

    ReferenceError: require is not defined in ES module scope, you can use import instead (no I can't.)

    and then early suggestions of --experimental-specifier-resolution=node is deprecated.

    👍React with 👍4Reacted by Daniel, -=<yb4f310, Jonathan MASSUCHETTI and nra
23. GeoffreyBooth commented on Aug 30, 2023

    

    GeoffreyBooth

    on Aug 30, 2023

    Member

    More actions

    import { createRequire } from "node:module"
    const nativeModule = createRequire(import.meta.url)("./native.node")

    👍React with 👍4Reacted by Andrew Johnston, tedy5, Theo Paris and Del Wang
24. d3x0r commented on Aug 30, 2023

    

    d3x0r

    on Aug 30, 2023

    Contributor

    More actions

    file1.cs

    module.exports=require("./native.node" );

    fileUse.mjs

    import whatever from "./file1.js"

    Still 2 lines - just 1 in an extra file.
25. guybedford commented on Aug 31, 2023

    

    guybedford

    on Aug 31, 2023

    Contributor

    More actions

    Personally, I also continue to be surprised no one ever landed this.

    👍React with 👍31Reacted by Daniel, Huy-GV, lsh, Jonathan MASSUCHETTI, Maciej Jur, theprojectsomething, Tim Fish, Jamie Birch, ncking, Dennis Duda and 21 more
26. crystalfp commented on Nov 11, 2024

    

    crystalfp

    on Nov 11, 2024

    Last edited by crystalfp

    More actions

    @JonasBa I made the change in my application and seems there are no problems at least on Windows. Now I'm waiting for the test on Linux. Also Linux has no issues.
27. nodejs-github-bot

    added a commit that references this issue on Dec 20, 2024

    esm: add experimental support for addon modules

    ...

    b6df128
28. aduh95

    added a commit that references this issue on Jan 2, 2025

    esm: add experimental support for addon modules

    ...

    cdb631e
29. richardlau

    added a commit that references this issue on Sep 22, 2025

    esm: add experimental support for addon modules

    ...

    d302cb3