Use productName from app/package.json if present

[tmm1]

This allows you to specify a productName for your executable which contains spaces and other special characters not allowed in the name property.

This matches similar behavior already present in electron-packager: https://github.com/electron-userland/electron-packager/blob/d49b932d88fee06173535efdcab225de98bfe95b/index.js#L59

[mention-bot]

By analyzing the blame information on this pull request, we identified @develar to be a potential reviewer

[develar]

build field in app package.json is used to provide builder configuration. So, I prefer to move it to build and rename to name (because name in the package.json is semantically the same).

What do you think? Or your concern is that productName in the root is a standard and we should follow (to avoid double configuration)?

About test — I will write (currently I rewrite tests, so, don't waste time to avoid merge conflicts).

[tmm1]

I don't have a strong preference. With the current location, it works with
both electron-packager and electron-builder.

On Fri, Mar 4, 2016 at 12:19 PM, Vladimir Krivosheev <
notifications@github.com> wrote:

build field used to provide builder configuration. So, I prefer to move
it to build and rename to name (because name in the package.json is
semantically the same).

What do you think? Or your concern is that productName in the root is a
standard and we should follow (to avoid double configuration)?

About test — I will write (currently I rewrite tests, so, don't waste time
to avoid merge conflicts).

—
Reply to this email directly or view it on GitHub
#204 (comment)
.

[develar]

it works with both electron-packager and electron-builder.

You don't need electron-packager if you use electron-builder (just to be clear).

Thanks, I will support both variants (name will be recommended).
Also, I am not sure about Linux, but it is up to user (so, it can be addressed in another PR (in any case fpm will convert to lowercase and throw warning)).

[tmm1]

BTW I think we should also rename the resulting binaries on OSX to use "productName" and "productName Helper" instead of Electron, as outlined in https://github.com/atom/electron/blob/master/docs/tutorial/application-distribution.md#os-x

[develar]

@tmm1 2.9 (tag: next) will be published in 30 minutes. Please try. Thanks for contribution (well, actual fix was complex — see #224).

[tmm1]

I tried 2.10.1 and it is not working as I expect. The zip and dmg filenames do not use productName as intended.

[develar]

@tmm1 Because these artifacts intended to be downloaded and space is unsafe char. For example, GitHub removes spaces from the filename on GitHub release upload.

Well, I am not expert here and it is why your feedback is important. Do you think that we should use product name in these artifacts names?

[tmm1]

I am not using GitHub releases. S3 and other web servers handle special
chars without any issue, using standard uri encoding (for example replacing
spaces with %20)
On Tue, Mar 22, 2016 at 1:08 AM Vladimir Krivosheev <
notifications@github.com> wrote:

@tmm1 https://github.com/tmm1 Because these artifacts intended to be
downloaded and space is unsafe char. For example, GitHub removes spaces
from the filename on GitHub release upload.

Well, I am not expert here and it is why your feedback is important. Do
you think that we should use product name in these artifacts names?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#204 (comment)

[develar]

Fixed (#262), will be available today as part of 3.0 release. Please note — on GitHub will be still published using package name, but not product name.

BTW I think we should also rename the resulting binaries on OSX to use "productName" and "productName Helper" instead of Electron, as outlined in

Fixed in the electron-packager and fix will be available in the same electron-builder 3.0 release.