fix(linux): productName should be used as the default value when executableName is not set per docs (#9068)

[hbcraft]

I have conducted tests in my project and it seems there are no issues.

Fixes: #8766

The above content is translated by a translation tool. Please ignore any errors in it.

[changeset-bot]

🦋 Changeset detected

Latest commit: 72b2996

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 8 packages

Name	Type
app-builder-lib	Patch
dmg-builder	Patch
electron-builder-squirrel-windows	Patch
electron-builder	Patch
electron-forge-maker-appimage	Patch
electron-forge-maker-nsis-web	Patch
electron-forge-maker-nsis	Patch
electron-forge-maker-snap	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[hbcraft]

I saw that Test App ßW.xml was generated during the test instead of testapp.xml. Should I change testapp.xml in the test file to Test App ßW.xml? Or is there any other way for me to fix this error?

The above content was translated by a translation tool. Please ignore any errors in it.

[hbcraft]

I changed testapp.xml in test/src/linux/debTest.ts:107 to Test App ßW.xml, and the tests running on my computer passed, but I don't know if this change is reasonable.

The above content was translated by a translation tool. Please ignore any errors in it.

[mmaietta]

This looks correct but I'll need to double check the full logic flow when I can find a chance. (Currently working on some other high-pri issues)

[mmaietta]

@hbcraft is this resolving a specific github issue? Just wondering if there's an issue we can link this PR to for closing it

[hbcraft]

As the id #8766 in the title

The above content was translated by a translation tool. Please ignore any errors in it.

[tjcouch-sil]

FYI Because I am uploading to snap, this broke my build. My name has only alphanumeric and dashes, but my productName has a period. I imagine you probably don't want to retroactively consider this a breaking change; just noting.

I fixed the problem by setting executableName in the linux property in my electron-builder config.

[mmaietta]

Hmmm thanks for calling that out. I am hesitant to consider this a breaking change as it's technically fixing a bug -> prod behavior is different than what the jsdoc's states the behavior should be.

Just curious, what did you set the executableName to?

[tjcouch-sil]

Here is the change I made. My package.json has "name": "platform-bible", but my electron-builder config has productName: 'Platform.Bible', so I needed to add executableName: 'platform-bible' in the linux property in the electron-builder config.

Indeed, I figured it would be difficult to consider this a breaking change. Reminds me of this XKCD comic:

[Vendicated]

I think this should be considered a breaking change and probably warrant a new major once it makes it into stable. Even if it's just a bugfix, it still breaks existing setups (the xkcd comic shared by TJ is quite on point 😅)

Changing the .exe and .desktop file name breaks features like autostart (since existing autostart desktop files will still refer to the old binary name) and dbus interactions. For me this made some of my dbus messages not work right, because chrome's CHROME_DESKTOP env var was still the old .desktop file name for whatever reason. I also use a wrapper bash script as the app's entry point (for adding command line flags that can't be added via electron api) and that is also broken by the binary rename.

Another example is #9234

I resolved these issues for myself so I don't mind, but just wanted to share my thoughts

[mmaietta]

@Vendicated good call out. I think in the future the default approach should be to change the documentation to match the prod behavior to avoid potentially-breaking changes like this one seems to be.

I can revert this such that it doesn't make it into "stable"/latest tag. What are your thoughts?

[Vendicated]

Not sure honestly. Personally I think the old default was more sensible. Isn't product name meant to be basically free text that allows special characters and spaces? Not great for binary names 😅

Maybe it'd make sense to make executableName a required property in a future update? Because name could also contain special characters if you use a scoped name (@scoped/name)

[mmaietta]

Well I'm just worried of the 236,273+ weekly downloads of devs using latest/26.0.12 tag then encountering this as an issue whenever 26.0.16 is promoted to latest/stable.

Making executableName required is a breaking change and I'm thinking of a quick revert of this PR will avoid a broader regression occurring in the ecosystem for the features you described (autostart + dbus).

[tjcouch-sil]

I haven't been in this headspace for a bit, so I can't say what I think makes sense to be honest. However, I'll give some thoughts based on the info I do have.

It seems this change is likely significant enough to be considered a breaking change since multiple users have run into it already, but I'm not used to this product environment such that I can say if that's actually all that significant.

Regarding what to do moving forward, I think it would be reasonable to consider the big picture here across operating systems and deployment targets:

• What fields are potential candidates for the executable name?
• What is currently happening across all operating systems and deployment targets?
• Are there any general conventions within operating systems and deployment targets that could guide these decisions?
  • For example, I could see some conventions suggesting no spaces in file names in certain environments or something. Or no special characters or no this or that.
• What restrictions are placed on executable names across operating systems and deployment targets?
  • For example, snap has specific limitations that Linux probably doesn't. I suspect the snap limitations probably match well to the npm package name limitations (so maybe using name from package.json makes sense in this context), but I could be wrong.
• Considering the conventions and restrictions, is there a sensible default that reasonably should happen across operating systems and deployment targets?

With these considerations in mind, would it make sense to use field x in all situations? Or field y in some others? Or maybe it's all too spread out and convoluted and we don't have time to look for a "perfect" solution, so maybe just pick one, make sure the documentation and the functionality are in line, and put it on a breaking release?

For example, you could change the code and the documentation so executableName defaults to productName in all conditions except some set of exceptions:

• snap: uses package.json name
• Any other exceptions we know of

Or just keep it simple and go with either executableName or package.json's name

Just some thoughts. I don't have time to do all this research and considering, and I appreciate if you don't, either. Do what you think is appropriate ;)

Thanks for your thoughtfulness and hard work! So thankful for this package. Keep up the great work!

[mmaietta]

Thank you all for your input. Will revert this PR change and update the documentation to reflect the previous behavior.

#9346