Skip to content
This repository has been archived by the owner on Nov 7, 2023. It is now read-only.

Addon node module not found in packaged windows version #2

Open
alexlyp opened this issue Sep 28, 2017 · 12 comments
Open

Addon node module not found in packaged windows version #2

alexlyp opened this issue Sep 28, 2017 · 12 comments

Comments

@alexlyp
Copy link

alexlyp commented Sep 28, 2017

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
Copy link
Author

alexlyp commented Sep 28, 2017

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
Copy link
Author

alexlyp commented Sep 28, 2017

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

@ushu
Copy link
Owner

ushu commented Sep 29, 2017

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
Copy link
Author

alexlyp commented Sep 29, 2017

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
Copy link
Author

alexlyp commented Sep 29, 2017

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
Copy link
Author

alexlyp commented Sep 29, 2017

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
Copy link
Author

alexlyp commented Sep 29, 2017

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
Copy link
Owner

ushu commented Sep 29, 2017

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

@smt116
Copy link

smt116 commented Oct 4, 2017

@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
Copy link
Owner

ushu commented Oct 4, 2017

@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
Copy link

smt116 commented Oct 5, 2017

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
Copy link

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants