Should the project move away from the 2 package.json structure?

I recently asked a question in electron-rebuild (used by this project as well as electron-builder) and was told by an experienced Electron community member that it’s a bad idea to use the 2 package.json structure with electron-rebuild.

https://github.com/electron/electron-rebuild/issues/253#issuecomment-426833695

I was wondering if you’ve considered moving away from the 2 package.json structure? It seems that since version 8, electron-builder is smarter about how it rebuilds native dependencies…

From https://www.electron.build/tutorials/two-package-structure

Since version 8 electron-builder rebuilds only production dependencies, so, you are not forced to use two package.json structure.

I’m not an expert in this area, but happy to help if this sounds like a good idea.

About my project if it helps understand my context:

• Based on electron-react-boilerplate
• Uses the 2 package.json structure
• Needed to modify ElectronRebuild.js to use electron-rebuild’s --which-module because I need to exclude node-sqlite3 from my electron-rebuild command because I need to build node-sqlite3 from source so that I can use SQLCipher encryption for SQLite.
• My current ElectronRebuild.js. I use electron-rebuild to rebuild all modules except for node-sqlite3. After rebuilding other modules, I compile node-sqlite3 from source with SQLCipher support.

[HyperSprite]

@vikr01 - I just ran tests with and without jest > moduleDirectories in the package.json and it passes either way.

11:25 $ yarn run test
yarn run v1.9.4
$ cross-env NODE_ENV=test BABEL_DISABLE_CACHE=1 node --trace-warnings -r babel-register ./internals/scripts/RunTests.js
 PASS  test/reducers/counter.spec.js
 PASS  test/actions/counter.spec.js
 PASS  test/components/Counter.spec.js
 PASS  test/containers/CounterPage.spec.js

I can’t run the E2E test right now. I’m still using Spectron in my project and not setup for TestCafe on my box yet.

If that’s all good, I could probably do a PR later today.

[HyperSprite]

Let me start by saying, I love this project, it let me get going on an Electron app really quickly. I truly appreciate all of the work that has gone into ERB.

TL;DR - I’m going to see if I can migrate to Rollup.

@aguynamedben - yep, umzug fails when built but not in dev or test (using an electron test runner). I’m fairly certain it has to do with path working different when built. I now realize I have been battling this issue for five months in one way or another, writing work arounds, etc to get sqlite/sequelize to work the way I need it to (not that Sequelize makes anything any easier). I thought this was an Electron issue this whole time, something I just had to deal with. Thanks for bringing this topic up, I am pretty much at a dead end at this point.

I’ve been poking around at various ideas for the best way to migrate off of webpack all night (I’m based on ERB v0.13 but made too many changes to continue to merge) but I could probably help backport my work once I’m done since my build portion is mostly the same as v0.15 (except for a adding a markdown loader).

Have you looked at Rollup? Rollup has polyfills for require that seem to be more Electron friendly, from what I can tell. I found this Rollup Electron Boilerplate so it’s possible. This boilerplate build process is so much simpler, I am wondering what is missing as far as building goes. It is also using Sass but there is a rollup-plugin-postcss that can handle css modules. I’m only minimally using the app.global.css for my stuff since I am using inline styles in my app.html and switching to JSS as soon as I load my bundle. I’m going to work on this this weekend, I’ll let you know how it goes.