electron-forge make node-pre-gyp error #1588
Comments
|
Hey @stefanJi 👋🏻 I can't seem to reproduce this. What version of |
|
maybe sqlite3 version auto upgrade, for |
|
I didn't do anything and it was solved |
|
👋🏻 This can be reproduced with Webpack probably because of this package dependencies error. which indeed seems to happen between 5.0.2 and 5.0.3 |
|
I'm still getting this now, using sqlite3 5.1.4 and electron-forge 6.0.4. And downgrading sqlite3 to 5.0.2 doesn't work because it gets HTTP 403 errors downloading the files :( |
|
I solved it by adding |
|
|
I made a workaround for this issue that completely removes node-pre-gyp from the packaged electron application. I am no expert in making native packages for nodejs. I use them, as many people do, and I recently tried to package one of them, node-sqlite3, to be a part of electron app. I use webpack and electron-forge for packaging. This tools produces a self-contained package, in the form of zip archive, debian, or rpm package. The package is OS and CPU architecture-specific (e.g. linux-x64) and it contains, as a part of electron binary, a specific version of nodejs. In the usual setup, webpack collects the bundle which contains the node-sqlite3 package. That bundle is collected from the local files. At that point, the node-sqlite3 package already contains platform-specific binary files. As a next step, that webpack bundle is packaged along with the electron runtime to the resulting application package. When running the resulting electron application on the end user machine, it is not expected to download any additional native binaries, compile them, cross-compile binaries to target other platforms, or upload compiled native binaries to the cloud storage. Problem is, that functionality is a part of node-pre-gyp and it's dependencies, and all that, being the runtime dependency of node-sqlite3, is packed by the webpack to the resulting application bundle. That packaging process is not without issues: in the current version of node-pre-gyp it may require to have a webpack configuration workaround of The bigger picture is, as I see it, that node-pre-gyp should not be a part of electron application bundle at all. It have it's place in the build pipeline, but carrying it further to the end-users should be avoided. I may not see some cases when it do required, but as far as I could tell, native modules, as soon as they are installed, could work fine without node-pre-gyp. At runtime, node-sqlite3 uses node-pre-gyp to resolve native module filename. There is a The electron application is already packaged for a specific environment, so I believe that template string could be resolved to a static path at the time of application packaging. That will effectively remove the need to include node-pre-gyp in the electron application package. The following code could be added to a webpack configuraton file to do exactly that. const path = require('path');
const fs = require('fs');
const nodePreGyp = require('@mapbox/node-pre-gyp');
const webpack = require('webpack');
// The following block assumes that the current file is in the project root, so we could calculate paths as relative to __dirname
const sqliteBindingPath = nodePreGyp.find(path.join(__dirname, 'node_modules', 'sqlite3', 'package.json'));
const sqlitePatchFileName = 'sqlite3-binding-with-binary-find-patch.js';
const sqlitePatchFilePath = path.resolve(path.join(__dirname, 'node_modules', 'sqlite3', 'lib', sqlitePatchFileName));
// Here we might write an absolute path. Webpack will take care to produce a portable bundle, in which this
// absolute path will be changes to a path, relative to the bundle itself.
fs.writeFileSync(sqlitePatchFilePath, `module.exports = require(${JSON.stringify(sqliteBindingPath)});`);
// Add this to your webpack config
module.exports = {
plugins: [
new webpack.NormalModuleReplacementPlugin(
/sqlite3\/lib\/sqlite3-binding\.js$/,
`./${sqlitePatchFileName}`
)
]
};The resulting bundle will not contain node-pre-gyp and it's dependencies. That will solve the current issue with packing ( I hope that this workaround might be of an inspiration to someone to create a more universal solution. It could be a lightweight runtime as a part of node-pre-gyp, or, if that is not possible, as a form of some alternative lightweight project. Maybe it could be solved on a side of packages such as node-sqlite3, and not on the node-pre-gyp side. Maybe package managers such as npm could came up with some abstractions to handle native modules that could help in this regard. |
The text was updated successfully, but these errors were encountered: