electron/forge

Npm link-ed native modules are not relocated

Closed this issue · 3 comments

Preflight Checklist

  • I have read the contribution documentation for this project.
  • I agree to follow the code of conduct that this project follows, as appropriate.
  • I have searched the issue tracker for a bug that matches the one I want to file, without success.

Issue Details

  • Electron Forge Version:
    • 6.0.0-beta.54
  • Electron Version:
    • v11.1.1
  • Operating System:
    • Windows 10 (20H2)

Expected Behavior

The native addon is relocated, copied to .webpack/native_modules, loads & works.

Actual Behavior

The addon is not copied at all, therefore bindings does not locate the .node file.

To Reproduce

I created a reproduction repository based on the webpack template (npx create-electron-app my-new-app --template=typescript-webpack): https://github.com/artus9033/electron-forge-webpack-native-module-MWE

Steps to reproduce:

  1. git clone https://github.com/artus9033/electron-forge-webpack-native-module-MWE
  2. npm i
  3. cd src
  4. cd native
  5. npm i (postinstall will configure & build the addon)
  6. npm link
  7. cd ../..
  8. npm link native-module
  9. npm run start will greet You with an error dialog:

image

Seems like the relocator does not detect the native module at all, as neither does it electron-rebuild it (it works, as the native module I created compiles with cmake-js to target the specific electron ABI installed by electron-forge), nor does it copy the .node binding into the .webpack directory:

image

If I just copy the whole module to node_modules, it works like a charm, but this is a McGyver-style solution.

I guess the reason may lie in @MarshallOfSound 's webpack-asset-relocator-loader fork.

Same here. Using yarn workspaces webpack seems to completely ignore the symlinked node modules.
Possibly related to vercel/webpack-asset-relocator-loader#113

Minimal repro is available here:
https://github.com/ivancuric/forge-symlink

If this is still an issue, it's an upstream issue.

It seems like definitely something got better, as now explicitly importing the built .node file works both in development & after packaging/making, although there are still 2 problems, both can be overcome with simple tricks, but present some inconvenience.

  1. The issue is still partly present, though: bindings do not seem to be handled properly and - in that case - the app works only in development, but packaging / making does not bundle the .node at all, of course speaking of a case when the native module is local to the project.
    This means that bindings cannot be used for such local native modules, which presents an inconvenience in development, but anyway, the fact to be able to make things 'just work' with directly-imported .node local modules is fantastic.
    For that, I updated the reproducible example. The bindings problem appears if line 3 in src/index.ts is uncommented in favor of line 4, and then the app is packaged.

image

  1. Another problem, probably even more serious, is that the native module is not detected if it is npm link-ed or npm i ./local-path-to-native-package: in the first case, it only works in development, and in the latter, it does not work at all neither in dev, nor after packaging, presenting an error log identical to the one I attached to the first comment in this issue.
    This issue, however, can be easily overcome the way I shown it in the reproducible MWE, by flattening project structure, merging all buildscripts into the root package.json and, most importantly, setting the output directory to <project root>/build (e.g. npx cmake-js -O ./build -d ./src/native). Generally, this can be reproduced using the previous version of my MWE, after updating @electron-forge/... deps to beta-60 and migrating to @vercel/webpack-asset-relocator-loader.