ushu / node-addon-loader

A loader for node native addons
https://github.com/ushu/node-addon-loader
MIT License
17 stars 26 forks source link

Addon node module not found in packaged windows version #2

Open alexlyp opened 6 years ago

alexlyp commented 6 years ago

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

alexlyp commented 6 years ago

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

alexlyp commented 6 years ago

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

ushu commented 6 years ago

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

alexlyp commented 6 years ago

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!

alexlyp commented 6 years ago

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

alexlyp commented 6 years ago

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.

alexlyp commented 6 years ago

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.

ushu commented 6 years ago

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:

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

smt116 commented 6 years ago

@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 /.

ushu commented 6 years ago

@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...

smt116 commented 6 years ago

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).

new-furry commented 1 year ago

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