Nativefier/app/webpack.config.js

36 lines
1.0 KiB
JavaScript
Raw Permalink Normal View History

Fix failing to global-sudo-install due to postinstall script (fix #923) As documented in https://github.com/jiahaog/nativefier/issues/923#issuecomment-599300317 , - #923 is caused by installing placeholder app deps at nativefier *install* time, with yarn (8.0.2) or npm (8.0.3). This is new in Nativefier 8.x, for the motivations behind it, see https://github.com/jiahaog/nativefier/pull/898#issuecomment-583865045 - During testing, I did test global installs, but never to a system / non-user-writable path (my `$npm_config_prefix` is set to `"$HOME/.node_modules"`) - But without such a config and when installing globally to a non-user-writable/system path with `sudo npm i -g nativefier`, - Installation of nativefier core works... - ... but then `postinstall` tries to do its job of installing app deps, and fails in various OS-dependent ways, but all about access rights. I suspect that, although main nativefier install runs as `su` with access rights to system paths, `postinstall` scripts are run *out* of `su`. That would make sense for security reasons: out of hook scripts, npm knows exactly what will be touched in your filesystem: it's the static contents of the published tarball; a postinstall script with sudo rights could do nasty dynamic stuff. So, although I don't see any mention of that in [npm-scripts docs / hooks](https://docs.npmjs.com/misc/scripts#hook-scripts) and I haven't dug npm/cli's code, I can understand it. So, reverting back to `webpack`ing the placeholder app, as done pre-8.0.
2020-03-17 02:06:03 +01:00
const path = require('path');
// Q: Why do you use webpack?
// A: https://github.com/nativefier/nativefier/commit/cde5c1e13bdc2739604cab04bac64eae0d719ed1
Fix failing to global-sudo-install due to postinstall script (fix #923) As documented in https://github.com/jiahaog/nativefier/issues/923#issuecomment-599300317 , - #923 is caused by installing placeholder app deps at nativefier *install* time, with yarn (8.0.2) or npm (8.0.3). This is new in Nativefier 8.x, for the motivations behind it, see https://github.com/jiahaog/nativefier/pull/898#issuecomment-583865045 - During testing, I did test global installs, but never to a system / non-user-writable path (my `$npm_config_prefix` is set to `"$HOME/.node_modules"`) - But without such a config and when installing globally to a non-user-writable/system path with `sudo npm i -g nativefier`, - Installation of nativefier core works... - ... but then `postinstall` tries to do its job of installing app deps, and fails in various OS-dependent ways, but all about access rights. I suspect that, although main nativefier install runs as `su` with access rights to system paths, `postinstall` scripts are run *out* of `su`. That would make sense for security reasons: out of hook scripts, npm knows exactly what will be touched in your filesystem: it's the static contents of the published tarball; a postinstall script with sudo rights could do nasty dynamic stuff. So, although I don't see any mention of that in [npm-scripts docs / hooks](https://docs.npmjs.com/misc/scripts#hook-scripts) and I haven't dug npm/cli's code, I can understand it. So, reverting back to `webpack`ing the placeholder app, as done pre-8.0.
2020-03-17 02:06:03 +01:00
module.exports = {
target: 'node',
entry: './src/main.ts',
devtool: 'source-map', // https://webpack.js.org/configuration/devtool/
module: {
rules: [
{
test: /\.ts$/,
use: 'ts-loader', // https://webpack.js.org/guides/typescript/
exclude: /node_modules/,
},
],
},
// Don't mock __dirname; https://webpack.js.org/configuration/node/#root
node: {
__dirname: false,
},
// Prevent bundling of certain imported packages and instead retrieve these
// external deps at runtime. This is what we want for electron, placed in the
// app by electron-packager. https://webpack.js.org/configuration/externals/
externals: {
electron: 'commonjs electron',
},
resolve: {
extensions: [ '.ts', '.js' ],
},
output: {
filename: 'main.js',
path: path.resolve(__dirname, 'lib'),
},
mode: 'none'
};