Addon node module not found in packaged windows version

I'm currently using node-addon-loader to attempt to pull in a C++ node addon into our electron application decrediton. It is currently working while using a hot-loaded dev environment and when running the windows-unpacked version. But after installing the electron-builder windows NSI and running the install .exe it no longer is able to locate the required .node

webpack config:
https://github.com/alexlyp/decrediton/blob/ayp_anotherTry/webpack.config.base.js#L35-L41

require(win32ipc):
https://github.com/alexlyp/decrediton/blob/ayp_anotherTry/app/main.development.js#L306

Any thoughts as to why it isn't working after installing verses windows-unpacked? Any help would be greatly appreciated! Cheers

In my logs when it can't be found it states Cannot open <some_hex>.node: Error: The specified module could not be found.

I see in my generated main.js that this is the path that trying to be resolved.

Hello,
I have only access to a Mac right now, I will look into it this afternoon when I have access to a Windows box.

in the meanwhile can you give the dev (master) version a try ?
just change your package.json to point to ushu/node-addon-loader#master and update the package.

This version requires at least Webpack 2 but looking at your project it should cause no issue, and it re-introduces the use of the loader's API emitFile function I had issues with on Webpack 1. Maybe that's why electron-builder is not working...

Another idea would be to open you package and look for calls to dlopen: it's the function used to open the shared lib (aka "node addon") and so you can easily review the code generated by the loader.

Regards

Ok updated to master and giving it a try.

I am using only require("/relative/path/to/addon") so no direct dlopen usage AFAIK.

Question about the functionality of the basePath option: That sets the path to the addon to be relative to the launched executable? I suppose I'm a bit confused by its intent.

Cheers for the help!

Ah after reviewing the webpack built main.js I See:

global.process.dlopen(t, "../<hex>.node")

And the matching <hex>.node file the same directory as my webpack.config.js

From what I can see, it keeps emitting the <hex>.node file in the same location and whatever I use for basePath doesn't seem to effect that location.

So I believe I fixed the issue I was having by adding an explicit directory setting:
https://github.com/alexlyp/node-addon-loader/blob/master/index.js#L39-L41

While not perfect, this seems to properly have the files accessible for the packaged version.

I was never able to figure out the reason why my setting of basePath was resulting in ..\_dirname

So I can leave this issue open for that if you'd like, otherwise you can close.

I could not make your code work on my Mac, so I could not investigate much, but I made a few changes to the code on master that might be helpful:

I made the plugin use the publicPath by default: it can help (but not in your case)
In addition basePath which does not seem to work in you case I added a new rewritePath option to let you override completely the path outputted in the JS code:

  // Load C++ modules
  { 
    test: /\.node$/,
    use: [
      {
        loader: "node-addon-loader",
        options: {
          // force all modules to be loaded from "XXX/<hash>.node" regardless the context webpack detected
          rewritePath: "XXX"
        }
      },
    ],
},

So in you case you can force the code to load the module from "resources" with rewritePath: "resources".

This feature is not yet documented, but you can find it on master

@alexlyp

@alexlyp check what is a cwd in the runtime while trying to load a native package. It is probably the root of the host instead of the application's directory.

I'm not a 100% sure why this package doesn't work, but there is something wrong with building a path in the runtime. I'd the same problem when building an electron application and solved it by resolving path in the runtime. In my case, the dlopen was trying to open a path like hex.node that was living in the application package, but the cwd in the process was /.

@smt116

@smt116 the issue might be that an electron app is not a "standard" web app and webpack kinda get confused.

For eg. if your build process produces files as follows:

electron-app.js
dist/                  <- webpack ouput dir
    index.html 
    bundle.js

then in a usual web app you make your web server point to dist and bundle.js (& all the other files) appear to be accessible from ./.
Electron is a bit different, you can tell electron to load dist/index.html, but then it expects the path of the resources required to be relative to the "root" path and not dist.

btw I am no webpack expert, so I could not figure a better way to handle this issue... Maybe your are right and using __dirname and such is the solution, but it seems a bit hacky to me...

In my case, all files from the dist are copied directly into the electron's application directory (as the asar package). Unfortunately the cwd of the process is / of the host. It might be an electron problem or maybe I've something misconfigured. Anyway, resolving a path in the runtime was my only idea in this case because I cannot inject any path there (the application executable may be placed in any directory by the end user).

@ushu

Hello @ushu. thank you for your great work.
I am not familiar with webpack as well. so I would like you to help me on this. I am trying to use your package.
Could you please help me to get this fixed? I am using my custom module that use .node file. it's working on dev mode as well.
But when I build it, it can't find module properly.
I followed your readme description. but still getting error.
Please reach me out. thank you

Navigation Menu

Repository navigation

Addon node module not found in packaged windows version #2

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Addon node module not found in packaged windows version #2

Description

Activity

alexlyp commented on Sep 28, 2017

alexlyp commented on Sep 28, 2017

ushu commented on Sep 29, 2017

alexlyp commented on Sep 29, 2017

alexlyp commented on Sep 29, 2017

alexlyp commented on Sep 29, 2017

alexlyp commented on Sep 29, 2017

ushu commented on Sep 29, 2017

smt116 commented on Oct 4, 2017

ushu commented on Oct 4, 2017

smt116 commented on Oct 5, 2017

new-furry commented on May 17, 2023

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions