`npm ci` does not modify the package-lock.json file, which is exactly what we want during packaging time. Otherwise, on Windows, npm will attempt to remove the mac-only dependencies like appdmg from package-lock.json.
Electron now offers a "armv7l" build on Linux. Because we were
specifying "all", we were generating an armv7l binary which was being
included in "WebTorrent-vX.X.X-linux.zip" along with the ia32 build,
which explains why it was 90MB+ in the last release.
Fixes two portable app bugs, to make the app fully "silent", not just
"portable". This means that not only are all data files stored in the
"Portable Settings" folder, but the app should leave no trace on the
host system.
- Disable Electron's single instance mode so no lock file is created in
"%APPDATA%\Roaming\WebTorrent".
- Put Electron crash files, and other electron files into the "Portable
Settings\Temp" folder instead of "%APPDATA%\Temp".
Pros of bubel over babel:
- No configuration (a la standard)
- Runs twice as fast, for quicker development
- Converts everything to ES5 (which is likely to be faster than ES6,
untested)
- Easy to swap Babel back in -- low commitment
Cons:
- Less battle-tested than Babel, but recommended by React core
developer so probably not too bad
- No babel plugin support, but we're not using that right now anyway.
Can switch back to babel if we need that later
BEFORE:
$ time npm run build
> webtorrent-desktop@0.16.0 build /Users/feross/code/webtorrent-desktop
> babel --quiet src --out-dir build
npm run build 3.07s user 0.27s system 115% cpu 2.902 total
AFTER:
$ time npm run build
> webtorrent-desktop@0.16.0 build /Users/feross/code/webtorrent-desktop
> buble src --output build
npm run build 1.38s user 0.16s system 114% cpu 1.343 total
Right now all Windows users are running a 32-bit app, even if their OS
is 64-bit.
Here's the plan to improve things:
1. We release a 64-bit installer, in addition to the 32-bit installer.
2. We auto-detect in the browser when a visitor is on a 32-bit vs.
64-bit OS and try to offer them the right installer. When in doubt, we
give them the 32-bit installer since that's safest.
3. The auto-updater will return the right binaries for the architecture
the user is on. This means that all our existing users who have 64-bit
OSs but are running the 32-bit app will get updated to the 64-bit app
on the next update. Also, 64-bit users who accidentally download the
32-bit installer will also get the 64-bit app on the next update.
---
Other notes:
- We don't generate 32-bit delta files. See reasoning inline.
- The package script now deletes extraneous Squirrel files (i.e.
*.nupkg delta files for older versions of the app) which should make
uploading the right files to GitHub easier. :)
The binary file naming works like this:
- Most users are on 64-bit systems, so they get nice clean file names
that don't specify an architecture (WebTorrentSetup-v1.0.0.exe). The
32-bit build files have the same naming but contain the string "-ia32"
at the end. In a few years, we will be able to just stop producing the
32-bit build files entirely.
- This means that the "WebTorrent-v0.15.0-linux-x64.zip" linux build
file is changing to "WebTorrent-v0.15.0-linux.zip" to match the Windows
naming convention. The .deb installer files must contain to
architecture in order to install correctly, so those do not change.
- Mac is 100% 64-bit, so it does not change.
Before this change, .torrent files would only be associated to
WebTorrent Desktop if another torrent client (like Transmission) was
installed on the system.
That's because one of the user's apps needs to define
"UTExportedTypeDeclarations".
On a fresh machine, without Transmission, WebTorrent Desktop now
associates .torrent files correctly.
So it will appear in the "Open With..." menu and the webtorrent
.torrent icon will be used for .torrent files.
Closes#542.
* packager: call callbacks consistently
Before this, the callbacks would not being called, which would lead to
an incomplete build on non-OS X platforms when trying to build all for
all platforms.
* packager: Always produce OS X update file regardless of --package option
This makes it consistent with how the windows build always produces the
.nupkg autoupdate files
* packager: fix duplicate npm install
Move "npm prune && npm dedupe" into the release script. Remove an extra
"npm install"
* Make Windows portable app
When a folder named "Portable Settings" exists in same folder as
WebTorrent.exe, then use it instead of the default application config
path.
Closes#358
* packager: remove redundant signing warning
* cross platform zip function
* Set config file path to match config.CONFIG_PATH
* portable app: make electron settings portable
* portable: fix poster/torrent paths
* use cross-zip
* portable app: default download folder inside 'Portable Settings'
* Many packager improvements; Windows signing!
* Windows signing works now! (Certs are on an external USB stick that
must be plugged into the build machine during build. We can't do the
same for OS X because certs need to exist in the login Keychain to be
found.)
Fixes#219
* Signing is now optional (so OS X and Windows contributors can run
`npm run package` without errors)
* zip, dmg, and deb arguments are now passed in as e.g. "--package=dmg"
* Print a huge warning when signing is disabled so we're less likely to
ship unsigned binaries to users.
* Make console.logs during packaging consistent and parallel
("creating..." followed by "created.")
* More aggressive signing warnings
* Warn when building OS X app on non-OS X platform (because signing
will never work on non-OS X platforms)
* Warn when building Windows app on non-Windows platform (because
signing doesn't work yet on non-Windows platforms)
* rm dist at start of build
* renderer style
* preload sound files for instant playback
The first time a sound file is played, the Audio object is cached.
5s after startup, all sound files are automatically preloaded.
