Introduction

Cargo NW is a redistributable package generator for applications developed using the Node Webkit application platform. Cargo NW generates application redistributables in a form of ready-to-use application folders, application archives, DMG images for MacOS, interactive installers powered by InnoSetup for Windows as well as Snapcraft images for compatible Linux distributions.

Cargo NW was developed to support next-gen WASM-powered applications developed in Rust on top of the Node Webkit platform and provides an ability to easily generate and build Rust-WASM-based desktop application templates.

While Cargo NW was designed to accomodate Rust WASM projects, it is capable of creating redistributables for traditional JavaScript projects. Cargo NW TOML manifest file format includes the ability to declare and build external dependencies and execute actions, allowing for customization of the application build process.

During the application integration process, Cargo NW will automatically download appropriate Node Webkit binaries, making it easy to switch between Node Webkit versions as well as the regular vs. SDK editions.

The goal of this tool is to simplify and automate the creation of redistributable packages, which in many cases can be an extremely tedious and a challenging process.

If you find this software useful, please consider supporting our development on Patreon. Your support allows us to improve and further customize this software for fellow developer needs. Please visit our website at https://aspectron.org for more information.

Installation

You can install cargo-nw from source using cargo. If Rust is not available, please see the Installing Rust section below.

Install and run cargo-nw using cargo:

cargo install cargo-nw

cargo nw --help

Installing Rust

To install cargo-nw from source, you need to install the Rust programming language as follows:

On Unix systems (Linux & MacOS) run:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

For Windows systems, download and run: rustup-init.exe

Alternatively, see other installation methods.

Dependencies

  • InnoSetup for Windows - allows creation of interactive Windows application installers
  • SnapCraft + LXD - allows building of redistributable images for compatible Linux distributions
  • WASMPACK if you want to build Node Webkit WASM applications in Rust

Operating Systems

To create installers you will need to run cargo-nw on each respective operating system. If you do not posess the hardware, you may be able to get around usign virtualization software such as Virtual Box for Windows and Linux and UTM for MacOS

Command Line

Cargo NW can be run as follows:

cargo-nw [flags] [manifest-location] <command> [command-flags]

[flags]:

  • --verbose - display additional information during the integration process

<commands>:

  • init - creates a manifest or a WASM application template
  • build - build a redistributable configured in the manifest
  • clean - remove intermedia files and dependencies
  • publish - execute a publish action configured in the manifest (useful for manually deploying built redistributables)

The init command

Cargo NW can create Node Webkit project templates. It can generate a basic Rust WASM application or only a manifest file (if integrating with an existing project).

To create a WASM template run the following:

cargo nw init

Similarly to npm init or cargo init this will create a project in the current folder, using the folder as a project name.

The init command accepts the following arguments:

  • name - optional name of the project. If omitted, cargo nw will use the current folder name and confirm the name with a prompt. If cargo nw detects an existing Cargo.toml or package.json file in the same folder, it will use the name from these pre-existing manifests.
  • js - (TODO) generate a classic Node Webkit JavaScript-based project (no WASM)
  • manifest - create nw.toml manifest file only
  • force - force overwrite any existing files (by default, cargo nw will abort if it detects any existing files)

The build command

Builing redistributables with cargo nw for different operating systems requires you to perform the build on the target operating system.

To build a redistributable you can use the following command:

cargo nw build <target>

Each target, except archive is specific to the operating system cargo nw is running on. archive targets are universal and produce a .zip file usable on the target operating system.

Following targets are available:

  • all - build all targets available on the current OS
  • archive - create a .zip archive of the redistributable
  • dmg - (MacOS) - generate a MacOS DMG image
  • innosetup - (Windows) - generate an InnoSetup interactive installer
  • snap - (Linux*) - generate a Snapcraft redistributable image

*) Please note that snap is compatible only with Linux distributions that support Snapcraft.

The build command supports the following options:

  • --sdk - builds the redistributable using Node Webkit SDK runtime (overriding the setting in the manifest file).
  • --dry-run - performs integration, but does not generate a redistributable image. You can find resulting files in the target/nw/build/ folder. If needed, you can test-run the application from the build folder.
  • --channel <'stable' or 'devel'> - Linux only - builds a snap image using the specified channel (overrides the setting in the manifest file).
  • --confinement <'strict', 'classic' or 'devmode'> - Linux only - builds a snap image using the specified confinement (overrides the setting in the manifest file).
  • --arch <'x64' or 'ia32'> builds a redistributable for the specified architecture (overrides the architecture of the current platform; can be used to build an ia32 build on x64 systems)

The publish command

Publish command executes all actions with the stage option set to publish. Unlike the deploy stage, that executes automatically after the integration process, publish stage is executed explicitly from the command line.

This command is useful to perform manual deployment of the generated redistributables.

Example of an action that runs at the publish stage:

[[action]]
stage = "publish"
items = [{ run = { cmd = "scp $NAME-$VERSION* user@host:releases/", cwd = "$OUTPUT"}}]

The clean command

The clean command removes intermedia files produced by cargo-nw.

cargo nw clean will delete build and cache folders (target/nw/build and taget/nw/cache).

cargo nw clean <flags> will clean intermediate files according to flags as follows:

  • --deps in addition to the above, will delete dependencies folder target/nw/deps

  • --dist will delete downloaded Node Webkit redistriutable releases folder $HOME/.cargo-nw

  • --all will perform all operations above

Manifest File Format

cargo-nw manifest file uses TOML configuration file format. By default, cargo-nw searches for nw.toml file in the current directory, however, you can specify an alternate file by specifying relative path or a path with a filename only. i.e. cargo nw app-lite build all (will use app-lite.toml file) or cargo nw ../build/app-full build all (will use ../build/app-full.toml file)

Most of the values specified in the manifest (except in the application section and script contents) can use internal variables that use $ prefix with the variable name in upper case (i.e. "$SOMEVAR"). For example:

[application]
...
version = "1.2.3"
title = "App Lite"
...
[windows]
resources = [{ ProductName = "$TITLE $VERSION" }]

There are two sections that can be present multiple times in the manifest: [[action]] and [[dependency]]. Sections that can be present multiple times are denoted by double brackets. These sections are processed in the order specified in the manifest.

The manifest contains the following sections:

  • [application] - application options
  • [description] - application description
  • [package] - integration options
  • [node-webkit] - node-webkit options (redistributable version etc.)
  • [[action]] - optional - integration actions
  • [[dependency]] - optional - dependency build options
  • [macos-disk-image] - optional - (MacOS) - DMG Finder window layout.
  • [windows] - optional - windows specific options
  • [images] - optional - image filename overrides
  • [languages] - optional - (InnoSetup) - installer languages
  • [firewall] - optional - (InnoSetup) - firewall rules for your application (should be present if your application makes network requests)
  • [snap] - optional - (Snap) - Snap configuration properties.

References

Certain manifest properties can reference external values. This is done by specifying an external .toml or .json file and a variable path as follows:

[application]
name = "Cargo.toml::application.name"
version = "Cargo.toml::application.version"
...
[description]
short = "Cargo.toml::application.description"
...

or

[aplication]
version = "package.json::version"

The reference contains 2 parts: <filename>::<variable-path> where <variable-path> is a dot-delimited path to the required sub-object property. The specified property must contain a string value.

This method makes it easier to track such values as a project version by allowing it to be set in a single location, especially when integrating cargo-nw into an existing project.

Variables

Most of the manifest properties (other than the [application] section) support injection of variables provided by cargo-nw during the integration process.

cargo-nw offers a set of internal variables created in the context of the ongoing integration combined with environment variables available at the time of execution.

Internal variables are:

  • $SOURCE - source project folder (specified in the manifest by package.root property)
  • $TARGET - destination folder (target application folder) - default target/nw/build/$NAME-$VERSION/
  • $OUTPUT - redistributable output folder - default: target/nw/setup/
  • $TEMP - temporary folder (located inside of the target/ folder) used by cargo-nw to store temporary information. This is not a system temp folder.
  • $PLATFORM operating system platform (windows,linux or macos)
  • $ARCH operating system architecture (ia32 or x64)
  • $NAME - manifest application.namevalue
  • $TITLE - manifest application.title value
  • $VERSION manifest application.version value
  • $ORGANIZATION - manifest application.organization value
  • $SHORT - manifest description.short value
  • $LONG - manifest description.long value
  • $AUTHORS - manifest application.authors value
  • $COPYRIGHT - manifest application.copyright value
  • $TRADEMARKS - manifest application.trademark value
  • $EULA - manifest application.eula value
  • $URL - manifest application.url value
  • $EXE- ".exe" on Windows and "" on unix
  • $BAT - ".bat" on Windows and "" on unix
  • $CMD - ".cmd" on Windows and "" on unix
  • $PS1 - ".ps1" on Windows and "" on unix
  • $SH - "" on Windows and ".sh" on unix

$EXE variable can be used to construct a binary filename where the filename on unix family of platforms may not have a filename extension, while on windows the extension may be .exe, as such specifying cmd = "my-app$EXE" will result in my-app.exe on Windows and my-app on unix.

Similarly, if you have a bash build script with an extension .sh and a PowerShell script with an extension .ps1 you can construct a filename my-file$SH$PS1 that will result in my-file.ps1 on unix and my-file.sh on unix.

In addition, environment variables available at the execution time of the cargo-nw are also available. As such, you can specify custom variables when running cargo-nw as follows:

MYVAR="ALPHA" cargo nw my-app.toml build all

Where the manifest file can use $MYVAR to spply options to internal actions, resource strings etc. For example:

[[action]]
items = [
    { run = { cmd = "myproc $HOME $MYVAR" }}
]

Actions

[application]

The application section declares basic application information.

  • name - the name of the project used as a prefix for redistributable packags and for internal identification of the application. This should be all lowercast alpha-numeric name with underscores or hyphens. Whitespace is not allowed.
  • title - the human-readable title of the application. This title will be used to name the appliation DMG image. This is also the title user will see in the Windows Start menu.
  • version - The version of the application in the "X.Y.Z" format.
  • organization The name of the organization, company or the development group producing this application.
  • authors optional
  • copyright optional
  • trademarks optional
  • eula optional
  • url optional - the URL of the product or the organization creating this application.

[description]

Description contains short and long descriptions of the application.

Both short and long descriptions are used in the Snapcraft package as a summary (short) and description (long). Due to Snapcraft restrictions, short description must not be longer than 78 characters.

Windows resources use short description to define FileDescription property, visible in the explorer application property window.

Long description can be multiline. The description section can be defined as follows:

[description]
short = "Neque porro quisquam est qui dolorem ipsum quia dolor sit amet..."
long = """
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod 
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, 
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo 
consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse 
cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat 
non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
"""

[package]

Package directive controls the packaging properties of the redistributable.

  • archive - ZIP archive format. Currenly only DEFLATE and STORE formats are supported. Cargo NW supports BZIP2 and ZSTD, unfortunately target operating systems do not alwasy support these formats and they should not be used.

  • signatures - when set to true this will generate .sha256sum files containing SHA256 hash of the resulting file. This can be used to fingerprint and validate the validity of the downloadable file. Beware - this is a superficial validation and does not protect you from malicious activity. For proper validation of redistributables you should use GPG key signing.

  • source - the source folder of the project relative to the nw.toml manifest.

  • build - The build directive supports two objects: WASM and NPM.

    • WASM will run wasmpack on the root folder before the integration process begins.
    • NPM will run npm install --omit dev on the root folder before the integration process begins.

  • resources - location of setup resources (icon files) relative to the location of the manifest file. By default this folder is resources/setup

  • include - include filters allowing glob or regex selection of the files that should be copied from the application root folder into the redistributable. By default, all files are included.

  • exclude - exclusion filter allowing glob or regex filtering of the files being copied to the redistributable application folder. In a typical configuration these should be set to exclude all folders that should be be a part of your redistributable, for example exclude = { glob = ["{bin/*,src/*,target/*,test/*,*.lock,*.toml,.git*}"]} If needed, you can specify multiple glob and regex entries that will be combined during the filtering process.

[node-webkit]

This section supports the following properties:

  • version - a string version of the node webkit that should be used during the integration.

  • sdk - a boolean true or false value that enables inclusion of NWJS SDK runtime in your application redistributable. This property can also be speified from the command line during the project build time as follows: cargo nw --sdk build all. Please note that including the SDK functionality into the redistributable can result in users gaining access to the internals of your application, as such, it is recommended to omit this flag (it is set to false by default) and specify it from the command-line when needed.

  • ffmpeg a boolean true or false value that enables inclusion of a fully-enabled community-built FFMPEG libraries available at https://github.com/iteufel/nwjs-ffmpeg-prebuilt/releases/ (please see below for licensing information)

PLEASE NOTE: Using MP3 and H.264 codecs requires you to pay attention to the patent royalties and the license of the source code. Consult a lawyer if you do not understand the licensing constraints and using patented media formats in your application. For more information about the license of the source code, please check here.

[[action]]

Actions allow execution of various operations at different stages of the package integration. Current supported commands are:

  • run executes an external application
  • copy copy files
  • write create a custom file with content
  • script create and execute a custom shell script

Actions acceps filters that denote at which stage or in which environment the action should run.

The following example will execute a script build-deps on Linux and build-deps.bat on Windows and then copy all binary files from deps/build/ to $TARGET/bin.

[[action]]
platform = ["windows","linux"]
stage = "build"
items = [
    { run = { cmd = "build-deps$BAT" }},
    { copy = { glob = ["deps/build/*$EXE"], to = "$TARGET/bin" }}
]

Filters

Please note that filters can be specified at the top level (for the action) or for any specific action item, allowing filtering at the action and at the item level.

stage property can have the following values:

  • build execute the script before the integration begins (before any files are copied)
  • package execute the script once the integration is complete (all files have been copied into the $TARGET folder)
  • deploy executes the script after redistributables have been built (useful to automatically publish redistributables)
  • publish executes the action only when user invokes cargo nw publish command.

platform list allows to specify one or more supported platforms:

  • windows
  • linux
  • macos

arch list specifies the system architecture

  • ia32
  • x64
  • (aarch64 is not supported as of writing this document but is planned to be supported when NWJS starts releasing aarch64-compatible builds)

family specifies the platform family and can have the following values:

  • windows
  • unix

Action Items

The following operations can be included in the list of action items:

  • run - executes an application of a command on the underlying operating system
  • copy - performs file copy
  • write - creates and writes content to a file
  • script - creates and executes a script on the underlying operating system

run

run directive allows execution of an external application

Example:

[[action]]
items = [{ run = { cmd="echo \"source: $SOURCE target: $TARGET\""} }]

or

[[action]]
items = [{ run = { argv=["echo","source: $SOURCE target: $TARGET"], cwd = "$TARGET" } }]

run supports the following options:

  • cmd - a string command to execute. Please note that to execute such command, the string is broken down into an array of arguments separated by spaces. As such, if the string contains file paths or arguments that contain spaces, this may create interference and result in the incorrect parsing of the arguments. Please use argv to specify explicitly each argument as it should be passed to the application.
  • argv - list of arguments to be passed to the application. First argument must contain the application name available in the system PATH environment variable.
  • cwd - working directory in which the application should be executed.
  • env - an array of environment variables passed as pairs as follows: ["K1=V1","K2=V2"]

run supports the following filter options:

  • platform - platform filter
  • arch - architecture filter
  • family - platform family filter

copy

copy directive provides file copy functionality.

copy supports the following options:

  • glob - an array of glob patterns. Creates a source file set based on the supplied set of glob patterns.
  • regex - an array of regular expressions. Creates a source file set based on the supplied list of regular expressions.
  • file - selects a single source file relative to the
  • to - destination folder (if used with glob or regex) or destination file (if used with file)
  • flatten - copies all files into the destination folder without preserving the original folder structure.
  • hidden - copies hidden files and folders (files or folder names starting with .) that are otherwise ignored.

copy supports the following filter options:

  • platform - platform filter
  • arch - architecture filter
  • family - platform family filter

Example:

[[action]]
name = "copy binaries"
items = [
    # copy all files in `bin` folder to $TARGET/bin
    { copy = { glob = ["**/bin/*"], to = "$TARGET/bin" }},

    # copy all files in `extern/bin` to $TARGET/bin
    { copy = { regex = ["extern/bin/[^/]+$"], to = "$TARGET/bin" }},

    # copy all files in `server/**/bin` and `client/**/bin` to $TARGET/bin
    # copy without preserving source folder structure (all files will copy to $TARGET/bin)
    { copy = { regex = ["server/.+/bin/[^/]+$", "client/.+/bin/[^/]+$"], to = "$TARGET/bin", flatten = true }},

    # copy all `.tpl` files from subfolders named `templates` and rename them to *.cfg
    # copy without preserving source folder structure (all files will copy to $TARGET/configs)
    { copy = { glob = ["**/templates/*.tpl"], to = "$TARGET/configs/*.cfg", flatten = true }},
]

[[action]]
name = "copy project config"
items = [
    # copy file and rename it
    { copy = { file = "template.cfg", to = "$TARGET/project.cfg" }}
]

write

write allows you to create a file with custom content as a part of the action execution.

write supports the following options:

  • file - name of the target file
  • content - file content

write support the following filter options:

  • platform - platform filter
  • arch - architecture filter
  • family - platform family filter

Example:

[[action]]
items = [
    { write = { file = "$TARGET/config/project.toml", content = """
    [config]
    name = "$NAME"
    """}},
    { write = { file = "$TARGET/package.json", content = """
    {
        "name": "$NAME",
        "version" : "$VERSION"
    }
    """}}
]

script

script allows for creation of a custom script during the integration process and execution of this script

script supports the following options:

  • type - script type: bash,sh,zsh,bat,cmd,ps1
  • name - optional - script file name
  • interpreter - optional the interpreter used to run the script (by default the interpreter is derived from the script type property)
  • script - script content

script supports the following filter options:

  • platform - platform filter
  • arch - architecture filter
  • family - platform family filter
[[action]]
items = [
# this is bash script that will run only 
# on Linux and MacOS dur to family filter
{ script = { type = "bash", family = "unix", script = """
echo "running Bash!"
""" }},
# this is CMD script that will run only 
# on Windows due to family filter
{ script = { type = "cmd", family = "windows", script = """
echo "running CMD!"
""" }},
]

[[dependency]]

Dependency directives allow building of external dependencies from a git repository and copying the resulting files into the target redistributable. This is useful when you integrate external applications as a part of your distributable.

Please note that if the dependency relies on 3rd-party build tools, these tools need to be installed and available in the system PATH environment variable.

Dependency processing steps:

  • git clone [-b branch] (if exists, git pull)
  • check last repository commit
  • if commit has changed, execute run directive (otherwise skip)
  • execute copy directive

[[dependency]] directive supports the following properties:

  • git - an object specifying the git repository from which to fetch the given dependency. This object supports the following options:

    • url specifying the git repository URL
    • branch - optional - specifying the branch. Example: git = { url = "https://github.com/org/repo", branch = "release" }

      The branch option, if present, is relayed to the git checkout command. if omitted, git will use the default branch.

    Please note that if branch name is changed, you will need to run cargo nw clean command to reset the cached dependency repository.

  • run - executes a command inside of the dependency folder. run supports the following options:

    • cmd - a string command to execute. Please note that to execute such command, the string is broken down into an array of arguments separated by spaces. As such, if the string contains file paths or arguments that contain spaces, this may create interference and result in the incorrect parsing of the arguments. Please use argv to specify explicitly each argument as it should be passed to the application.
    • argv - list of arguments to be passed to the application. First argument must contain the application name available in the system PATH environment variable.
    • cwd - working directory in which the application should be executed.
    • env - an array of environment variables passed as pairs as follows: ["K1=V1","K2=V2"]

    run supports the following filter options:

    • platform - platform filter
    • arch - architecture filter
    • family - platform family filter

  • copy - copies files from the dependency folder. copy supports the following options:

    • glob - an array of glob patterns. Creates a source file set based on the supplied set of glob patterns.
    • regex - an array of regular expressions. Creates a source file set based on the supplied list of regular expressions.
    • file - selects a single source file relative to the
    • to - destination folder (if used with glob or regex) or destination file (if used with file)
    • flatten - copies all files into the destination folder without preserving the original folder structure.
    • hidden - copies hidden files and folders (files or folder names starting with .) that are otherwise ignored.

    copy supports the following filter options:

    • platform - platform filter
    • arch - architecture filter
    • family - platform family filter

Example:

[[dependency]]
name = "kaspad"
git = { url = "https://github.com/kaspanet/kaspad", branch = "release" }
run = [
    # commands are executed in the repository folder
    { cmd = "go build" },
    { cmd = "go build", folder = "cmd/genkeypair" },
    { cmd = "go build", folder = "cmd/kaspactl" },
    { cmd = "go build", folder = "cmd/kaspawallet" },
]
copy = [
    { regex = [
        "kaspad(.exe)?$",
        "genkeypair(.exe)?$",
        "kaspactl(.exe)?$",
        "kaspawallet(.exe)?$",
    ], to = "bin/$PLATFORM-$ARCH", flatten = true },
]

[macos-disk-image]

This section controls the layout of the DMG image window as seen when opened by the user. This controls the window size, icon size and icon positions.

  • TBD window_caption_height - height of the Finder caption bar (default 60)
  • window_position - position of the DMG Finder window (default: [200,200])
  • window_size - size of the DMG Finder window (default: [485,330])
  • icon_size - size of icons (default: 72)
  • application_icon_position - position of the application icon within the window (default: [100,152])
  • system_applications_folder_position - position of the system "Applications" folder icon (default: [385,152])

Pleas note: the window size should match the supplied DMG background image folder.

[windows]

Windows section of the manifest contains Windows-specific definitions used by the interactive installer (InnoSetup)

Following properties must be set:

  • uuid- a UUID string identifying the application in the windows registry. This UUID is used by the installer during updates and the uninstall process.

  • group - a string value containing the name of the Start menu folder in which the application should be placed.

  • run_on_startup - a string value containing one of the following two values: "everyone" and "user". If "everyone" is specified, the application will auto-start for any user login. If "user" is specified, the application will auto-start only for the user that has installed the application.

  • run_after_setup - a boolean value true or false indicating whether the interactive installer should offer the user to run the application after the completion of the installation.

  • resources - contains a list of windows resource strings that should be included in the executable. For example, the following declaration will add CompanyName record set to the organization name and a custom resource value NW Project containing the application title: resources = [ { CompanyName = "$ORGANIZATION" }, { Custom = { name = "NW Project", value = "$TITLE" }}, ]

    Winows resource strings and values can be arbitrary. The following list of resource names is considered to be standard on Windows:

    • CompanyName
    • FileDescription
    • FileVersion
    • InternalName
    • LegalCopyright
    • LegalTrademarks
    • OriginalFilename
    • PrivateBuild
    • ProductName
    • ProductVersion

Please note that ProductName, ProductVersion, CompanyName, FileVersion, InternalName are set automatically to match the properties specified in the [application] section. Specifying them under the [resources] section will override the [application] section values.

[images]

Images section allows overriding default filenames for application icons.

NOTE: For Windows, application icon should be at least 512x512. For MacOS the application icon should be at 1024x1024 and preferably follow Apple design guidelines (you can download MacOS icon templates from here)

cargo-nw will automatically resize icon images and convert their formats where needed and embed them into all appropriate resources and application manifests.

Default image filenames

When searching for application icons, cargo-nw will search the resource files for the following images:

For application icon:

  • <platform>-application.png
  • application.png
  • default-application-icon.png

For document icon:

  • <platform>-application.png
  • application.png
  • default-application-icon.png

For DMG:

  • macos-disk-image-backgroun.png

For InnoSetup icon:

  • innosetup.png
  • windows-application.png
  • application.png
  • default-application-icon.png

For InnoSetup Wizard Large Image:

  • innosetup-wizard-large.png

For InnoSetup Wizard Small Image:

  • innosetup-wizard-small.png

Overriding image filenames

To change default filenames, you can specify the following properties under the [images] section. Please note that property names provide OS-specific overides with a fallback to default icons.

All images should be in the PNG format.

  • document - document icon (fallback)
  • windows-document - windows-specific document icon
  • linux-document - linux-specific document icon
  • macos-document - macos-specific document icon
  • application - application icon (fallback)
  • windows-application - windows-specific application icon
  • linux-application - linux-specific application icon
  • macos-application - macos-specific application icon
  • macos-disk-image - DMG background image
  • innosetup-icon - InnoSetup (fallback is the windows-application, followed by application)
  • innosetup-wizard-small - InnoSetup Small Wizard Image
  • innosetup-wizard-large - InnoSetup Large Wizard Image

[languages]

Contains a list of languages that should be enabled by the installer. Currently used in InnoSetup only.

Example:

[languages]
languages = [
    "english",
    "french",
]

The following installer languages are offered by InnoSetup and can be specified in the languages section:

  • armenian
  • catalan
  • danish
  • french
  • icelandic
  • norwegian
  • russian
  • spanish
  • brazilianportuguese
  • corsican
  • dutch
  • german
  • italian
  • polish
  • slovak
  • turkish
  • bulgarian
  • czech
  • finnish
  • hebrew
  • japanese
  • portuguese
  • slovenian
  • ukrainian

[firewall]

The firewall section currently works on Windows only and functions by embedding a call to netsh advfirewall into the InnoSetup script to be executed after the application installation.

The following properties are supported:

  • application an object containing direction property which can be set to contain in and out strings, depending on whether the application desires to be an outbound and/or inbound access.
  • rules - optional - a set of rules for additional executables that may be included with the application - an array of objects containing name, program and direction properties, where name is the firewall rule name, program is the executable filename relative to the program installation path and direction specifying the access direction (in and/or out)

Example:

[firewall]
application = { direction = "in+out" }
rules = [
    { name = "MyChildService", program = "bin\\windows-x64\\my-child-service.exe", direction="in+out" }
]

[snap]

  • channel - stable or devel - detailed information is available here.

  • confinement - strict, classig or devmode - detailed information is available here.

  • interfaces - additional interfaces that should be included in the application snap file. Default interfaces incuded are browser-support, network, network-bind, opengl, x11, upower-observe. A complete list of interfaces available can be found here.

  • packages - list of additional packages that should be included for ELF (dynamic linkage) resolution. This is only needed if you are including additional external binaries in your application. When including additional binaries, Snapcraft may produce ELF errors specifying missing libraries. You can then take the library prefix (name) and search for the packages that includes this library using the following command apt list | grep <package-substring>. Once the package has been identified, you can include it in the snap.packages list.

Please note: during the build Snapcraft may produce warnings about incorrect ELF paths. This is normal and as long as .snap file is produced, the application will function correctly.

Please note: if using strict confinement, Node Webkit will not be able to access GPU hardware and will fallback to software rendering mode. Depending on the functionality offered by your application, it is possible that it may experience other constraints. To mitigate this, you can try identifying and including required interfaces in the snap.interfaces list or use the classic confinement.

Registributables

InnoSetup

To build InnoSetup interactive installation redistributables, you need to download and install InnoSetup on your build system.

DMG

DMG builds do not require any additional tooling as DMG generation relies on the hdiutil included with MacOS.

Snap

Snap requires snapcraft to be installed on the linux operating system.

sudo apt install libssl-dev
sudo snap install snapcraft
sudo snap install lxd
sudo adduser <username> lxd
sudo service snap.lxd.daemon restart
# you may need to restart the system

When creating SNAP files, to install them locally you need to run:

# when building with `strict` containment
snap install --dangerous <yourfile>.app
# when building with `clssic` containment
snap install --dangerous --classic <yourfile>.app

Resources

If you are looking to develop cutting-edge HTML-powered interactive desktop applications in Rust, you are in the right place.

Rust offers a vibrant ecosystem of packages (crates) that can be built to WebAssembly available at https://crates.io.

Following crates provide base-layer functionality for Node Webkit application development: