revery-ui/revery-packager

Helper utility to package Revery applications into installable app bundles

revery-packager

Utility inspired by electron-builder for bundling Revery applications into installable application packages.

This is extracted out from the Onivim 2 packaging scripts, and provides a way to get redistributable executables from your Revery projects.

This packager takes care of some of the heavy lifting, like:

• Windows: Bringing in the proper set of runtime DLL dependencies
• OS X: Bundling dylibs and remapping rpaths to be relocatable
• Linux: Bundling so libs and remapping rpath's to be relocatable.

...but you don't have to worry about that - you can just run revery-packager and be good to go.

Installation

npm install -g revery-packager`

Usage

1. Ensure your Revery project is built and up-to-date (esy install, esy build).
2. Run revery-packager at the root of your Revery project.

You'll find the release artifacts for the current platform in the _release folder.

NOTE: Today, revery-packager doesn't support 'cross-platform' packaging - meaning you need to run revery-packager on each platform you wish to distribute builds. We recommend Azure Devops CI as a way build and get packages for all platforms - see our revery-quick-start pipeline for an example.

Configuration

You can customize the behavior of the packager by adding a revery-packager section to your package.json, like:

package.json

  "name": "revery-quick-start",
  "version": "1.3.0",
  "description": "Revery quickstart",
  "license": "MIT",
  "esy": {
    "build": "refmterr dune build -p App",
    "buildsInSource": "_build"
  },
  "revery-packager": {
    "bundleName": "ExampleApp",
    "bundleId": "com.example.app",
    "displayName": "Revery Example App",
    "mainExecutable": "App",
    "windows": {
      "packages": ["zip"],
      "iconFile": "assets/icon.ico"
    },
    "darwin": {
      "packages": ["tar", "dmg"],
      "iconFile": "assets/icon.icns"
    },
    "linux": {
      "packages": ["tar", "appimage"]
    }
  },
  ...

The following properties are configurable:

• bundleName - The bundle name of the application. Used for manifests and for the filename.
• bundleId - An identifier for the application. Used as the CFBundleIdentifier for Mac.
• displayName - Display name of the application, used for installers, desktop entries, etc.
• mainExecutable - The entry point for the application. There should be no .exe suffix added.
• packages - per-platform list of packages to build:
• dmgBackground - MAC-ONLY - background to use for DMG installer
• appImageType - LINUX-ONLY - type to use in the desktop entry for the AppImage
• appImageCategory - LINUX_ONLY - category to use for the desktop entry for the AppImage
• iconFile
  • Windows - an .ico file to use for the executable
  • Linux - a .png file to use the desktop entry
  • Mac - an .icns file to use for the app icon

You can also specify per-platform settings by using the windows, darwin, and linux sections - you probably want to do this for settings like iconFile.

Roadmap

• Windows
  • Code signing
  • zip package
  • exe installer
  • msi installer
• OSX
  • Code signing
  • Notarization
  • tar package
  • dmg package
• Linux
  • GPG signature
  • tar package
  • appimage package

License

MIT License

Copyright 2019 Outrun Labs, LLC

revery-packager's Issues

Better docs about icons

Had quite a lot debugging around using icons on macOS.

Problem 1

there is no documentation that you need to edit assets/dune (in revery-quick-start repo)
like

(install
    (section bin)
    (package App)
-   (files Roboto-Regular.ttf))
+   (files Roboto-Regular.ttf icon.icns))

Problem 2

documentation uses
"iconFile": "assets/icon.icns"
this doesn't correspond with what gets created when you add icon like I did in dune,
and leads person to expect their assets dir is used, but this is path inside *.App package. Even now I'm not sure if it is path inside Contents/MacOS/ or Conents/Resources but they are symlinked so it probably doesn't matter.

All in all little more docs would help here :)

API: Allow and/or prefer to use a standalone file for configuration

As to separate the logic and not clutter up esy-configurations I propose that we either allow for a separate config-file to be used, or refactor to only use a configuration-file.

E.g.

revery-packager.config.json

{
   "bundleName":"ExampleApp",
   "bundleId":"com.example.app",
   "displayName":"Revery Example App",
   "mainExecutable":"App",
   "windows":{
      "packages":[
         "zip"
      ],
      "iconFile":"assets/icon.ico"
   },
   "darwin":{
      "packages":[
         "tar",
         "dmg"
      ],
      "iconFile":"assets/icon.icns"
   },
   "linux":{
      "packages":[
         "tar",
         "appimage"
      ]
   }
}

Cannot resolve path '/usr/lib/libiconv.2.dylib'

os: Big Sur 11.4

I follow the revery-quick-start doc, and run revery-packager.

error info:

Bundling dylibs...
[shell] /Users/shuirong/.esy/3_______________________________________________________________/i/esy_macdylibbundler-0.4.5-f05b75c3/bin/dylibbundler -b -x "/Users/shuirong/Code/reasonml/revery-quick-start/_release/darwin/ExampleApp.App/Contents/MacOS/App" -d "/Users/shuirong/Code/reasonml/revery-quick-start/_release/darwin/ExampleApp.App/Contents/Frameworks" -p "@executable_path/../Frameworks/" -cd

/!\ WARNING : Cannot resolve path '/usr/lib/libiconv.2.dylib'

/!\ WARNING : Library libiconv.2.dylib has an incomplete name (location unknown)
libiconv.2.dylib does not exist. Try again
libiconv.2.dylib does not exist. Try again
libiconv.2.dylib does not exist. Try again
libiconv.2.dylib does not exist. Try again
......

I ll the /usr/lib/lib*, There is no libiconv.2.dylib indeed.

I searched Google and still haven't the idea.