plugin-electronegativity error: "warn: Couldn't detect Electron version, assuming v0.1.0"

[guizmaii]

Pre-flight checklist

• I have read the contribution documentation for this project.
• I agree to follow the code of conduct that this project uses.
• I have searched the issue tracker for a bug that matches the one I want to file, without success.

Electron Forge version

6.0.0-beta.63

Electron version

v18.1.0

Operating system

Ubuntu 20.04.4 / macOS 11.6.5 / Microsoft Windows Server 2022 10.0.20348

Last known working Electron Forge version

No response

Expected behavior

The Electron version must be auto-detected

Actual behavior

I configured the plugin-electronegativity in a brand new generated Electron+TS+Wepback project (thanks to https://www.electronforge.io/templates/typescript-+-webpack-template), following the plugin doc: https://www.electronforge.io/config/plugins/electronegativity

In my CI, running on Mac, Windows and Linux, when I run yarn make I have the following error:

warn: Couldn't detect Electron version, assuming v0.1.0. Defaults have probably changed for your actual version, please check manually.

Steps to reproduce

• Electron+TS+Wepback project with https://www.electronforge.io/templates/typescript-+-webpack-template
• configure plugin-electronegativity as explained here https://www.electronforge.io/config/plugins/electronegativity
• run yarn make

Additional information

No response

[erikian]

The Webpack plugin modifies the original package.json, setting devDependencies (as well as dependencies/optionalDependencies/peerDependencies) to an empty object here:

forge/packages/plugin/webpack/src/WebpackPlugin.ts

Lines 241 to 244 in 1f45e2c

	pj.devDependencies = {};
	pj.dependencies = {};
	pj.optionalDependencies = {};
	pj.peerDependencies = {};

When @doyensec/electronegativity attempts to read the Electron version from devDependencies, it finds none, hence the error.

I believe this could be fixed by simply not modifying the original package.json file. While removing dependencies from the distributed package.json can be desirable, plugins shouldn't really introduce any side effects like this one.

This behavior seems to exist just as an additional measure to prevent the whole node_modules directory to be packaged, as described in #593 (comment). But since the plugin already ignores anything outside the .webpack directory and does not call npm install, using the original package.json should be safe enough.