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:
git clone https://github.com/artus9033/electron-forge-webpack-native-module-MWE
npm i
cd src
cd native
npm i
(postinstall will configure & build the addon)npm link
cd ../..
npm link native-module
npm run start
will greet You with an error dialog:
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:
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.
- 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 thatbindings
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. Thebindings
problem appears if line 3 insrc/index.ts
is uncommented in favor of line 4, and then the app is packaged.
- Another problem, probably even more serious, is that the native module is not detected if it is
npm link
-ed ornpm 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 rootpackage.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 tobeta-60
and migrating to@vercel/webpack-asset-relocator-loader
.