Basically, use fpm

We only need list + extract-full, node-7z has un-normalized file lists, and bundles another promise implementation (when) which means we have an ugly wrapper.. at this point it's cheaper just to do it ourselves.

Tied to #25 since our squirrel callbacks should take care of that

That means making our dispatcher more ipc-aware, so it can wait on promises running on the node side. It's not impossible imho - if that fails we can always forget about promises in action callbacks and move back to separate events.

The upside to having AppStore live renderer-side is faster React rerenders (since it could then take advantage of immutable data structures), and less bandwidth needed between node and renderer (so less marshalling/unmarshalling going on).

Right now if you:

• Start a download
• Quit halfway
• Start the app again

The download will resume but the progress bar will start from 0, as if you hadn't downloaded anything before.

That basically makes downloads a priority queue, should be able to move up/down & pause individually.

Apparently this game has one.

Top test material 💯

Since the last pre-release, the directory layout has been updated significantly, we now need to make use of a few ignore patterns to make sure our install remain as lean as possible.

Electron has node-integration so it is actually useless (and takes almost a full minute to install on travis!).

gulp was fun (and necessary for our browserify usage imho) but we have to use grunt anyway for packaging/making installers so once #5 is done, I'm saying goodbye to grunt.

Turns out it's awesome:

• Squirrel/Squirrel.Windows#446 (comment)
• http://pouchdb.com/2015/03/05/taming-the-async-beast-with-es7.html
• http://bluebirdjs.com/docs/api/promise.coroutine.html
• https://babeljs.io/docs/advanced/transformers/other/bluebird-coroutines/

...and supported in Electron (both renderer & browser side)

Lots of sane changes: http://bluebirdjs.com/docs/new-in-bluebird-3.html

The needle promisification will be significantly less weird

We're currently using mock-require, which is cool but:

• It's easy to forget to stop mocking (you have to call stop / stopAll explicitly)
• There's no easy way to let calls fall through the mock to the original module
• 🐼

I vote we switch to proxyquire which had me confused when I looked at it originally but actually seems to make perfect sense and even plays well with sinon which we are using.

Especially relevant now that we have #20, #21 and #49 - also #22 is looking more important than ever, perhaps right after #19 is done?

Ideally that'd be fixed server-side but we already kind of have schemas for client-side data persistence so we might as well normalize it in the client too.

Right now we only grab the first 15 items

Pointers: https://github.com/LinusU/node-appdmg/blob/master/lib/hdiutil.js (but less hacky)

Silent install is possible: http://www.jrsoftware.org/ishelp/index.php?topic=setupcmdline

Whenever the new electron release is out we can revert to the official version

Since migrating to ES6, I've gone back and forth on several styles to use for importing and exporting module, and after facewalling a few times, here's a style that actually works for several different purposes:

// importing a whole module into a 'namespace', or
import module from 'path/to/module'
// ...just importing what we need
import {Louie, Huey, Dewey} from 'path/to/lawsuit'

let self = {
  // no need to go for ES6's fat arrow syntax, there's no 'this' to bind to
  foo: function () {
    // hey we need to call another function in our own module, refer to it via `self`
    // so that it can be mocked.
    return self.bar() + 1
  },

  // this one can be mocked, or tested independently, so that's cool. it could even
  // be split into another module later, but for now it doesn't do much harm here
  bar: function () {
    return 11
  } 
}

// this will work both when required via es6 module syntax or via simple require syntax
export default self

Some other styles are still around, but they'll all be changed as more tests get written against them.

Blocking both processes is a huge performance issue.

Aka read a few more articles on best practices to test React applications. Honestly it's probably going to be something like 'given X input, does component Y render at all?'. And maybe stuff like fake input events but that would imply mocking some of the flux architecture (probably just the action creator?)

Cf. https://github.com/atom/electron/blob/master/docs/api/app.md#appmakesingleinstancecallback

Very minor issue: Markdown needs to be installed in order to run the dev setup due to the README.md file itself. So, it should probably be added to the list of install dependencies in the README.md file itself or removed from the Tuprules file.

$ tup
[ tup ] [0.000s] Scanning filesystem...
[ tup ] [0.005s] Reading in new environment variables...
[ tup ] [0.005s] No Tupfiles to parse.
[ tup ] [0.005s] No files to delete.
[ tup ] [0.006s] Executing Commands...
* 1) markdown < README.md > README.html
/bin/sh: markdown: command not found
 *** tup errors ***
 *** Command ID=235 failed with return value 127

My solution was to install markdown via homebrew:

$ brew install markdown
==> Downloading http://daringfireball.net/projects/downloads/Markdown_1.0.1.zip
######################################################################## 100.0%
🍺  /usr/local/Cellar/markdown/1.0.1: 2 files, 40K, built in 2 seconds
$ which markdown
/usr/local/bin/markdown
$ tup
[ tup ] [0.000s] Scanning filesystem...
[ tup ] [0.004s] Reading in new environment variables...
[ tup ] [0.004s] No Tupfiles to parse.
[ tup ] [0.004s] No files to delete.
[ tup ] [0.004s] Executing Commands...
 1) [0.100s] markdown < README.md > README.html
 [ ] 100%
[ tup ] [0.124s] Updated.

The rest of the setup was a success, though!

Pointers:

• Linux: gotta check if this solution is enough, saint XDG pray for us
• Windows: a few registry tricks in squirrel handler, see the basic format and how atom modifies the registry
• OSX: can specify in Info.plist, even supported by electron-packager

When it's correctly registered, the Electron app will receive an open-url event.

To do all things properly, we should probably get in touch with someone at IANA, perhaps Dave Thaler ?

request is fat:

something like

https://commondatastorage.googleapis.com/itchio/https://some-external-website.com?GoogleAccessId=etc.

On the chrome side

Launching electron works well, and it's travis-friendly, using the same trick as electron's own tests to communicate to command-line.

Still have to figure out how to test React components, might steal a thing or two from Jest? But gave up on using it out-of-the-box (too slow & doesn't integrate with electron afaict)

On the remote side

This one is pretty trivial, just haven't settled on a test framework yet - I'd like to keep them as close to the chrome tests as possible.

Good summary: http://www.advancedinstaller.com/user-guide/msiexec.html

I own too many games :(

Although it definitely should. Gotta investigate.

I thought we needed that, but we probably don't, we can simply use the ignore directive from https://github.com/maxogden/electron-packager

install store is doing it wrong

Here's what I think happen{ed,s}:

• image URLs used to be https://img.itch.io/something
• now they're //img.itch.io/something (protocol-relative URL)
• since electron is loading a file:// resource, it's trying to open file://img.itch.io/something

Afaict it's as simple as calling setFeedUrl and checkForUpdates when manually checking.

In fact I'd really like to have.. an update store that responds to CHECK_FOR_UPDATE and emits stuff like UPDATE_AVAILABLE, UPDATE_READY

@leafo all that's needed to support that is for the various download API endpoints to also list 'web' downloads (possibly with a new field, embed = true ? and have the game type (html5, flash, etc.) in the various game json objects in collection endpoints etc.) - ideally the client would directly download the zip and extract it locally.

Copying a library over should be trivial, absolute paths prevent that

We're only using it for formatBytes, not worth it - besides, humanize-plus already does that for us

When setting up nyc + coveralls to have nice reporting of how much of our app is covered by tests, I misunderstood how nyc worked, turns out it's actually a wrapper over istanbul and it would work with pretty much any test runner.

So there was no need to migrate to tape in the first place! which means we can switch back to AVA to get parallel tests. Note that this depends on #10 because I'm pretty sure mock-require acts at the global level and that would've been a dealbreaker in AVA anyway.

https://github.com/arqex/fluxify looks like it supports waitFor when actions return promises, which would be really cool.

For example, assuming we have prereq-store, api-store, and ui-store, on BOOT

• ui-store (current 'app-store') would wait on api-store to know if we get to login via cached credentials or if we need to login from scratch, and on prereq-store to make sure we can run the app properly
• api-store would try to retrieve credentials from the config
• prereq-store would run the current setup task, simply

It's all the same action it's just different tasks that need to be coordinated, I think it makes sense in the flux infrastructure.

Silent install is possible: http://nsis.sourceforge.net/Docs/Chapter3.html#installerusage

However NSIS installers look like regular .exe files, so must find a way to sniff'em