Package name vs. Product name

[anseki]

Hi, thank you for great tool.

Is there a way to package with a name that is not productName?
electron-packager-6.0.0 seems to naming with productName like productName.app or productName.exe.
I want to specify a human-readable product name that might be long and it might include space, comma, etc,.

As actual example, "Microsoft Office Word" is specified as product name to WINWORD.EXE.

I specified name option and version-string.ProductName option for Windows, then name.exe that has ProductName as file property was created. This result has come up to my expectations.
But, CFBundleDisplayName and CFBundleName fields for OS X were set name. I want to set productName to these.

[malept]

I'm not clear on what you're asking. Could you please write some explicit steps to reproduce the behavior you're seeing (vs. what you expect)?

This is what I did:

git clone https://github.com/atom/electron-quick-start && cd electron-quick-start
$EDITOR package.json # Added `"productName": "Electron Quick Start",` (minus the backticks) under the "name" key
npm install
npm install --save-dev electron-packager
$(npm bin)/electron-packager . --all

Expected: CFBundleName and CFBundleDisplayName are set to Electron Quick Start, not electron-quick-start.

Actual: In Electron Quick Start-darwin-x64/Electron Quick Start.app/Contents/Info.plist, the relevant key-value pairs look like this:

    <key>CFBundleDisplayName</key>
    <string>Electron Quick Start</string>
    <key>CFBundleName</key>
    <string>Electron Quick Start</string>

[anseki]

Yes, productName is set to CFBundleName and CFBundleDisplayName, but productName is used to name of files and directories, name is ignored.
Then Electron Quick Start.app, Electron Quick Start.exe, etc., are created.

These include spaces.
Product name might include more special characters, for example ".Net foo bar" (a dot at first), and ® is commonly used. http://unicode.org/cldr/utility/character.jsp?a=00AE

I hope that name option or name key of package.json (e.g. electron-quick-start) is used to name of executable file and other folders, and productName (e.g. Electron Quick Start) is used to property of executable file and fields of plist such as CFBundleDisplayName.
I can do that by name option and version-string.ProductName option for Windows (don't set productName), but I don't know a way to set to fields of plist.

[malept]

One of the things that we could do is strip out any non-word-or-whitespace character from generated filenames.

What I'm trying to avoid is a pages-long list of parameters and/or possible package.json keys. It's bad enough already.

[anseki]

I think that name (i.e. short lowercased name) should be used as name of files and folders, and productName (i.e. application's full capitalized name) should be set to file property or field of plist.
For example, the original electron executable file is named electron.exe and its Product Name property is Electron. (for Windows. but folders for OS X are named Electron.app.)

Anyway, I can already control the name of generated files and folders by name option.
And I can specify a product name by version-string.ProductName option for Windows.
But, specific plist fields with extend-info option for OS X are overridden by name.

So, I wrote a build task script that changes those fields to proper product name.

[malept]

I am not opposed to this idea, but it will require a major version bump.

[anseki]

Ok, I understand that.
For the time being, I use task script.
I think that a note should be added to document, that say: productName or name of package.json or name option should be safety string that is used to name of files and folders.

Thank you for your time 😄

[kfranqueiro]

At least on OS X, .apps very often have title-cased names. I'd be wary of electron-packager suddenly becoming magically opinionated about that.

[malept]

To be clear, I was not endorsing forcing Mac .app folders to always be set to package.json's name. I do forsee bugs being filed in the future about how certain names cannot be generated because the filesystem is not Unicode-based.

[erkyrath]

Someone could file a bug like that today.

I agree that it's desirable to permit (not require) a split between human-readable name fields (CFBundleName, CFBundleDisplayName) and filesystem names (CFBundleExecutable). And I'd rather do it with an additional (optional) option than have the packager try to transform my input into a "safe" format.

[anseki]

And also, a name that includes spaces of an executable file may make problem.
The important point is that we don't make productName include space and special characters when we use electron-packager. In many cases, name is safety (because that is used to repository name, directory name, etc.), but productName may include spaces.
I think that this should be added to document.

[malept]

And also, a name that includes spaces of an executable file may make problem.

When would spaces in an executable name be a problem?

[anseki]

Spaces in a path that is not quoted are recognized as separator according to context that starts the application.
For example, adding a path to an application launcher, specifying a path of favorite editor such as Atom to git, setting-up a task scheduler, and specifying a path in command line like shell (but in this case, user will find spaces), etc. Users will not perceive that in GUI operation.
path/to/Electron Quick Start.exe is split to path/to/Electron and Quick Start.exe as two options.

[malept]

It's more likely that /path/to/Electron, Quick, and Start.exe would be the options, but when would you be using a shell in Windows (or any other OS) and not know to quote arguments with spaces?

(By the way, the version of electron-builder I'm using generates installer files for Windows that are named $APP_NAME Setup.exe, which wouldn't surprise me if that was the default for NSIS.)

[erkyrath]

Nearly all Mac apps are not meant to be started up from the command line. If you're building one that is, I think it's in your lap to either not use spaces or document for your users how to quote spaces.

[malept]

Nearly all Mac apps are not meant to be started up from the command line. If you're building one that is, I think it's in your lap to either not use spaces or document for your users how to quote spaces.

Agreed.

[anseki]

Sorry, my English is very poor.
Did you ask me about cases that users don't quote a path?
For example, some file selectors with GUI dialog box don't make user think a path, such as adding a path to an application launcher, task scheduler, etc.

Anyway, characters that have meaning for file system (e.g. :, \, /, *, ?, ", space, etc.) should not be included in productName.

I think that installer files are usually started in Windows explorer by user operation, therefore it may be not problem.

@erkyrath, as I said, path in command line is ok, because user will find spaces.
Some application launchers require paths of applications. Before, that threw an error about space included folder name.

Anyway, for the time being, I use task script to fix productName. And an issue in my case is solved.

[anseki]

So, don't you think adding the information about productName to document?

electron-builder's document says clearly: name doesn't allow spaces and special characters, and productName allows those.
https://github.com/electron-userland/electron-builder/blob/master/docs/options.md#application-packagejson
grunt-build-atom-shell's document also says clearly that the productName is used to name of generated files.
https://github.com/paulcbetts/grunt-build-atom-shell#options
(not package.json)

I think that the note should be added to document, that says: productName and name of package.json or name and appname option should be safety string that doesn't include spaces, /, \, :, . at first, etc.
The rule about name of package.json is defined, but since electron-packager handles productName like name, that should be shown in document.

[develar]

Related: electron-userland/electron-builder#204

I don't see anything wrong in the current electron-packager behaviour.

electron-packager packs your app and produce one artefact. App file. If you specify product name, you expect that it will used in all places. As @tmm1 said and I am agree.

electron-builder produces nupkg, deb/rpm/etc and other deployment artefacts (in a distributable format). Publish to GitHub releases. In this case we must use only name and it is expected. Also, for example, electron-builder uses name in the icon path on Linux instead of product name to avoid unsafe chars (because icon layout is under the hood and is not visible to end user).

So, I don't think we should change current behaviour. Option to change exe name may be added (but I don't like it — yet another option + "Nearly all Mac apps are not meant to be started up from the command line" + it is ok to use Google Chrome/App Store/LEGO Digital Designer on OS X).

[develar]

As actual example, "Microsoft Office Word" is specified as product name to WINWORD.EXE

And what? Do you start MS Office using terminal (cmd)? Or using Spotlight (I mean poor windows alternative Cortana/Start)? How does it affect end user? In any case you should create desktop shortcuts on Windows and do not distribute electron-packager result (instead, you should create Squirrel.windows app file using electron-builder or tool like that).

[anseki]

Hi @develar, thank you for your advice.
I could not understand your advice completely, but those may help me.
Anyway, as I said, an issue in my case was already solved by task script or electron-builder.
And I suggested adding the information. (#297 (comment)) Because those unsafe characters (e.g. /, \, :, .) often be used for product name.
p.s. I gave WINWORD.EXE as an example of the product name that differs from the executable file name. Not an example of problems. and of course I don't start MS Office from terminal.

I say again, an issue in my case was already solved. I just thought that the information about productName may help someone. Someone might use /, \, :, etc., for product name.

[malept]

FYI, there's a different bug to strip special path characters from generated filenames: #308

[dmythro]

Hi. So, is it possible to set the Original filename? Now it's set as electron.exe in built *.exe Properties.
And having the filename without spaces would be also sweet.

[malept]

@Z-AX See: https://github.com/electron-userland/electron-packager/blob/master/docs/api.md#version-string

[dmythro]

@malept Oops, missed ¯_(ツ)_/¯. Excuses, all works as required.
Thanks for very fast reply!

[goodhyun]

Another reason to strip spaces from your file name:

MakeAppx : error: Error info: error C00CE169: App manifest validation error: The app manifest must be valid as per schema: Line 6, Column 13, Reason: 'File Name' violates pattern constraint of '[-.A-Za-z0-9]+'.

MakeAppx that is needed to get your app on Windows store doesn't like a filename with spaces.
Microsoft (R) MakeAppx Tool Copyright (C) 2013 Microsoft. All rights reserved.

[phoebejaffe]

This might be useful -- I did finally have success with this.

electron-userland/electron-builder#4287