My build used to only work if I had this flag --max_old_space_size=4096
I don't know if that should be necessary anymore, but I know trying to use it causes a failure.
I'm failing on this command during packaging: build-renderer:cross-env NODE_ENV=production node -r babel-register ./node_modules/webpack/bin/webpack --config webpack.config.production.js --progress --profile --colors``
Here's the full error log:
0 info it worked if it ends with ok
1 verbose cli [ 'C:\\Program Files\\nodejs\\node.exe',
1 verbose cli 'C:\\Users\\Slapbox\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js',
1 verbose cli 'run',
1 verbose cli 'build-renderer' ]
2 info using [email protected]
3 info using [email protected]
4 verbose run-script [ 'prebuild-renderer', 'build-renderer', 'postbuild-renderer' ]
5 info lifecycle [email protected]~prebuild-renderer: [email protected]
6 silly lifecycle [email protected]~prebuild-renderer: no script for prebuild-renderer, continuing
7 info lifecycle [email protected]~build-renderer: [email protected]
8 verbose lifecycle [email protected]~build-renderer: unsafe-perm in lifecycle true
9 verbose lifecycle [email protected]~build-renderer: PATH: C:\Users\Slapbox\AppData\Roaming\npm\node_modules\npm\bin\node-gyp-bin;C:\Projects\myApp\node_modules\.bin;C:\Users\Slapbox\AppData\Roaming\npm\node_modules\npm\bin\node-gyp-bin;C:\Projects\myApp\node_modules\.bin;C:\Users\Slapbox\AppData\Roaming\npm\node_modules\npm\bin\node-gyp-bin;C:\Projects\myApp\node_modules\.bin;C:\Users\Slapbox\.babun\cygwin\home\Slapbox\.local\bin;C:\Users\Slapbox\.babun\cygwin\usr\local\bin;C:\Users\Slapbox\.babun\cygwin\usr\local\bin;C:\Users\Slapbox\.babun\cygwin\usr\local\sbin;C:\Users\Slapbox\.babun\cygwin\bin;C:\Users\Slapbox\.babun\cygwin\home\Slapbox\.local\bin;C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\Microsoft SQL Server\130\Tools\Binn;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit;C:\Program Files\MySQL\MySQL Utilities 1.6;C:\Program Files\Perforce;C:\Users\Slapbox\AppData\Local\Programs\Python\Python35-32\Scripts;C:\Users\Slapbox\AppData\Local\Programs\Python\Python35-32;C:\Users\Slapbox\.babun;C:\Users\Slapbox\AppData\Roaming\npm\node_modules\jshint\bin;C:\Program Files\Perforce\Server;C:\Users\Slapbox\AppData\Roaming\npm;C:\adb;C:\Program Files\nodejs
10 verbose lifecycle [email protected]~build-renderer: CWD: C:\Projects\myApp
11 silly lifecycle [email protected]~build-renderer: Args: [ '/d /s /c',
11 silly lifecycle 'cross-env NODE_ENV=production node -r babel-register ./node_modules/webpack/bin/webpack --config webpack.config.production.js --progress --profile --colors' ]
12 silly lifecycle [email protected]~build-renderer: Returned: code: 2 signal: null
13 info lifecycle [email protected]~build-renderer: Failed to exec build-renderer script
14 verbose stack Error: [email protected] build-renderer: `cross-env NODE_ENV=production node -r babel-register ./node_modules/webpack/bin/webpack --config webpack.config.production.js --progress --profile --colors`
14 verbose stack Exit status 2
14 verbose stack at EventEmitter.<anonymous> (C:\Users\Slapbox\AppData\Roaming\npm\node_modules\npm\lib\utils\lifecycle.js:279:16)
14 verbose stack at emitTwo (events.js:106:13)
14 verbose stack at EventEmitter.emit (events.js:191:7)
14 verbose stack at ChildProcess.<anonymous> (C:\Users\Slapbox\AppData\Roaming\npm\node_modules\npm\lib\utils\spawn.js:40:14)
14 verbose stack at emitTwo (events.js:106:13)
14 verbose stack at ChildProcess.emit (events.js:191:7)
14 verbose stack at maybeClose (internal/child_process.js:877:16)
14 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)
15 verbose pkgid [email protected]
16 verbose cwd C:\Projects\myApp
17 error Windows_NT 6.1.7601
18 error argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\Slapbox\\AppData\\Roaming\\npm\\node_modules\\npm\\bin\\npm-cli.js" "run" "build-renderer"
19 error node v6.10.0
20 error npm v4.2.0
21 error code ELIFECYCLE
22 error errno 2
23 error [email protected] build-renderer: `cross-env NODE_ENV=production node -r babel-register ./node_modules/webpack/bin/webpack --config webpack.config.production.js --progress --profile --colors`
23 error Exit status 2
24 error Failed at the [email protected] build-renderer script 'cross-env NODE_ENV=production node -r babel-register ./node_modules/webpack/bin/webpack --config webpack.config.production.js --progress --profile --colors'.
24 error Make sure you have the latest version of node.js and npm installed.
24 error If you do, this is most likely a problem with the myApp package,
24 error not with npm itself.
24 error Tell the author that this fails on your system:
24 error cross-env NODE_ENV=production node -r babel-register ./node_modules/webpack/bin/webpack --config webpack.config.production.js --progress --profile --colors
24 error You can get information on how to open an issue for this project with:
24 error npm bugs myApp
24 error Or if that isn't available, you can get their info via:
24 error npm owner ls myApp
24 error There is likely additional logging output above.
25 verbose exit [ 2, true ]
Thanks very much for any suggestions!
Scratch that, I can use --max_old_space_size=4096 but it seems like it must be put directly after node in the command. I had had it after the -r
Will report in a few minutes whether build succeeded.
Still fails unfortunately.
It was added to increase the size of the heap. When live reloading, the webpack process would run out of memory. Not sure if that's a problem anymore. Let me know if removing it causes any issues during hot reload
No issues with hot reload, but can't package! =(
Does a clean install of the boilerplate work for you?
It does. I meant to update to say that I have tried that now.
I don't know where even to begin looking to resolve this. If you have any ideas to point me in the right direction, I'd be very appreciative.
Keeping up to date with the upstream is hard. We have to find ways to make this easier. I would recommend merging with the upstream frequently so that its easier to narrow the issue and the change set would be smaller instead of waiting for x number of releases to merge a huge change list
I will be doing so more often now with your advice on handling yarn.lock.
The only things of significance I can recall having changed on my end are the webpack.config files up to version 2, package.json scripts and some minor and patch version updates (besides webpack), and the main.development.js menu being moved out to a separate file.
And the root.js, which I'm not using. I don't recall having seen that file in the past? But maybe I'm mistaken. I do have a file with provider in any event.
I imagine it must be something in the webpack.configs
Running build-renderer is what fails for me.
When I run the script itself cross-env NODE_ENV=production node -r babel-register ./node_modules/webpack/bin/webpack --config webpack.config.production.js --progress --profile --colors rather than running npm run build-renderer it completes successfully. Where does this build to? Is there a way I could package without relying on the NPM script if need be?
Build-renderer builds to dist folder. This is different from packaging.
Are you using uglyifyjs or babili?
I agree the current processing of keeping up to date with upstream is a pain.
I'm using Babili. I've spent several hours on this and made no progress unfortunately.
It seems to complete all the same steps when run with npm or when I copy the command straight to the terminal, but fails immediately following the last step.
If I could build manually outside of npm scripts I would certainly be open to that. It seems like package is just a combination of build-main and build-renderer though? I'm not clear on how it creates the exe, or how it packages the exe into an installer.
Any advice?
I can give a complete rundown of the files changed by my update to the upstream, and it's quite minimal. I've even mirrored the use of the root.js now which I had not been prior, but no luck.
It seems like package is just a combination of build-main and build-renderer though?
The package command is responsible for building the project by using build-main and build-renderer. It then uses electron-builder to package the app into dmg, exe, etc. If you want more control over the packaging, I would recommend using it programmatically.
What I'm not clear on is how the package command is calling to run electron-builder?
command is calling to run electron-builder?
build --publish never. It is a bit confusing because we have a script called npm run build. The binary for electron-builder is called build
Ah I see. Thanks @amilajack I'll try to play around with what I know now and see if I Can't get a build together.
Try disabling babili in the webpack production (I think) config.
Usually my method of debugging something like this is to start disabling
things 1 at a time and see if it works when that is disabled. So that way I
at least know what is broken.
Something else to check is pull down a fresh copy of the boilerplate and
make sure it is working first. Then one at a time start adding the node
modules/deps. After each module is added and imported then try to build and
package to ensure it works. It could be getting stuck on a certain module.
You may have a module that needs to be moved to the app package.json
causing problems, for example.
@dustintownsend @amilajack Is there any better debugging available for webpack? I haven't gotten around to attacking this problem again yet.
Dustin, I do believe I disabled Babili and other plugins previously, and unfortunately it still failed.
@Slapbox disabling babli should do the trick
I did manage to get this working by running the build-main and build-renderer command outside of NPM, and then running the Electron-Builder outside NPM as well. It may directly result in this though: https://github.com/chentsulin/electron-react-boilerplate/issues/850
Most helpful comment
Keeping up to date with the upstream is hard. We have to find ways to make this easier. I would recommend merging with the upstream frequently so that its easier to narrow the issue and the change set would be smaller instead of waiting for x number of releases to merge a huge change list