Inconsistent Documentation/Behavior around App name

Preflight Checklist

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

Issue Details

• Electron Forge Version:
  • 6.0.0-beta.51
• Electron Version:
  • v8.2.3
• Operating System:
  • macOS 10.15.3
• Last Known Working Electron Forge version::
  • NA

Expected Behavior

I’m trying to set the Application name text in all instances. Using name in the bundler will name it as I have defined.

Actual Behavior

The packager config name will be used for the top level application name, but it still falls back to the package.json productName or name for the sub-level item naming (About xxx, Hide xxx, Quit xxx, etc)

To Reproduce

Calling electron-forge make to build.

package.json

{
	"name": "product-name",
	"productName": "Readable ProductName,
	"version": "1.0.0",
	"main": "src/main.js",
	"scripts": {
		"start": "nodemon --watch src --watch static --exec electron .",
		"start-no-watch": "electron .",
		"build": "electron-forge make"
	},
	"config": {
		"forge": "forge.config.js"
	},
	... etc
}

forge.config.js

const config = {
	packagerConfig: {
		name: 'Will Replace TopLevel',
		executableName: 'Keystone Omni Desktop',
		icon: 'assets/app.icns',
		appBundleId: 'com.xxxxxx.omni',
		appCategoryType: 'public.app-category.developer-tools',
	},
	makers: [
		{
			name: '@electron-forge/maker-zip',
			platforms: ['darwin'],
		},
	],
}
module.exports = config

Additional Information

According to the packager documentation:

The application name. If omitted, it will use the productName or name value from the nearest package.json.

What is not clear is that the specified name here is not used EVERYWHERE, and in some cases the package.json name is still used.

NOTE: Not sure if this is best applied to electron-forge or electron-packager, have not tested using electron-packager separately for the results there.

[russellpekala]

Can we reopen this? My team is having this problem. We can potentially open a PR later this week or next to address it. It is very difficult for us to have different dev and prod environments

[mix3d]

@MarshallOfSound Please reopen this ticket. Your comment is insufficient for the issue at hand. I created this issue from this StackOverflow issue: https://stackoverflow.com/a/62479773/3780922