Support setting boolean properties with -c.extraMetadata

[jviotti]

• Version: 18.6.2

• Target: debian

I need to set a boolean value using --extraMetadata, however it seems that this option only supports strings, therefore something like:

--extraMetadata.updates.enabled=false

Results in:

{
    "updates": {
        "enabled": "false"
    }
}

I haven't tested it, but I suspect the same issue applies to numbers.

Of course I can workaround this limitation from my application code, however I wonder if we could add support for values other than strings.

Some thoughts:

• We could check if the value equals false, true, or contains only numbers and coerce appropriately, however there might be cases where you really need to set something like "false"
• Maybe there can be --extraMetadataBoolean and --extraMetadataNumber options?

[develar]

19.4.0 allows you to specify extraMetadata in the config. Is it solution for you?

[develar]

Fixed in 19.7.0

[jviotti]

Sorry for the delay. I somehow missed the previous comment. The value of the variable I want to inject depends on certain make options, so having a configuration option would not be ideal.

Fixed in 19.7.0

What was the fix? Can you point me to a commit? I checked the CHANGELOG and the git history, but couldn't find anything relevant.

[develar]

What was the fix?

new Ajv({allErrors: true, coerceTypes: true})

coerceTypes was set to true.

[jviotti]

I just tested 19.7.0, but --extraMetadata.updates.enabled=false still results in a 'false' string.

[develar]

-c.extraMetadata.updates.enabled=false

[develar]

latest release is 19.8.0

--extraMetadata deprecation was not yet announced.

[jviotti]

I upgraded to 19.8.0 and ran --config.extraMetadata.updates.enabled but still the same result.

[develar]

Got it. extraMetadata typed as any and, so, not possible to convert. Well... is it ok for to specify it not in the CLI, but in the config file?

[develar]

19.9.1

[jviotti]

Well... is it ok for to specify it not in the CLI, but in the config file?

My particular use case is to disable auto updates on Debian and RPM packages (that we publish to Bintray repositories). Is there a better way to solve this with electron-publish?

[develar]

1. It is fixed. We just convert true/false strings to bool.
2. extraMetadata will not work in this case because we build app for platform and then pack it into distributable formats. So, deb/rpm will use the same source dir.

Currently, I don't see way except somehow in the runtime detect. But — in any case auto update is not supported on Linux yet and will be supported only for AppImage. And AppImage sets some special ens, so, you can detect that app is running from AppImage.

[lurch]

Minor correction to @jviotti 's previous comment - we're not actually auto-updating at the moment, but checking for a newer version of the app being available on the server than is running locally, and presenting a pop-up to the user if so. But obviously if the user has installed Etcher through some package-manager (like deb or rpm) we expect them to be updating through that, and we don't want to show them a pop-up that a newer version is available for manual download.

It is fixed. We just convert true/false strings to bool.

Thanks :)

[develar]

@lurch So, use process.env.APPIMAGE != null to check that app running using AppImage.

[timo955]

9e77231