Installing canary and the normal version alongside eachother

[ELLIOTTCABLE]

It's rather standard to be able to install the release-version, and future-version, of web technologies side-by-side: Chrome Canary, FireFox Nightly, WebKit Nightly, etc.

In looking to report a flashing-URL bug, I wanted to ascertain whether it's specific to the Canary version I'm using (2.0.4), or the if it exists in the release version (1.4.8) as well — but I realised it'd be a huge pain-in-the-ass to downgrade.

This is something of a problem, though: the two versions may require slightly different configurations … and, unfortunately, the current architecture requires the release-channel to be documented in the configuration file. Oops.

---

Here's, tentatively, one way that I see this working, without revisiting the config.updateChannel behaviour that was just established:

1. The configuration dot-file (~/.hyper.js) should default to checking for channel-specific versions first, based on the currently-being-initialized version of the app (i.e. if ‘stable’ is being booted, it reads from ~/.hyper.js; but if ‘canary’ is, it checks for ~/.hyper.canary.js first, before falling-back to ~/.hyper.js.)
2. The dot-directory used by Hyper should always correspond to the currently-being-initialized version — i.e. the above, but with no fallback: ‘stable’ uses ~/.hyper_plugins/, while ‘canary’ uses ~/.hyper_plugins.canary/, creating it if it does not exist.

This leaves ‘upgrading’ rather complex, currently, though: you'd have to first change ~/.hyper.js to ‘canary’ … launch Hyper.app, let it update … move the current release to Hyper Canary.app, and your config to ~/.hyper.config.js … re-download Hyper.app … copy your configuration back to ~/.hyper.js … and change that release-channel back to ‘stable.’

Yeah. Gross.

---

Ideally, I think, to improve the install, upgrade, and configuration experience, it'd be ideal if this were consolidated; and the update-channel were not a factor of configuration, but of the installation:

1. We could change the update-channel to be hard-coded into the installation, and not the config-file,
2. then add a web-page / UI / menu-item / hpm (or similar) command, that distributes or manages installed versions of Hyper,
3. with each thus-installed version of Hyper following the above-described fallback behaviour for configuration.

I hope this Issue is welcome; and this obviously isn't a high-priority concern, but it's something to think about and plan for, as Hyper gains in popularity, and we gain more plugins or themes (and plugin- or theme-developers) who need to test their work in the future releases, or report bugs in Hyper itself.

Thanks for reading!

[markozxuu]

@ELLIOTTCABLE Thank you for taking the time to write us this suggestion 😄

[albinekb]

This is how I wanted it too, and specified in https://github.com/zeit/hyper/issues/1925, but the others wanted it in this way 🤔 Don't know the full motivation why the current path was chosen. @rauchg, @leo ?

[ELLIOTTCABLE]

@MAPESO No problem!

If there's anything I can do help, let me know. Old-hat JavaScript'er / Node expert, and happy to contribute, but I'm a beginner to React and/or Electron.

[leo]

Sounds like a great idea to me! Our update system and Hazel already support this - we only need to make sure to have a separate config per channel.

Perhaps we should just have an additional property named canary or canaryConfig next to the existing config one in the config file, which could then overwrite any config sub properties? The advantage of that would be not having to keep multiple files in sync and not having to specify each config property again.

Let me know what you think - it's the best way to handle it IMO. 😊

[chabou]

It could be great to have different plugin or plugin versions (@last in stable and @next in canary for a given plugin). But yes, only one config file (with canary overwriting section) and adding a .hyper_plugins/canary/ directory should be perfect.

[ELLIOTTCABLE]

I don't want to over-engineer, but that does sound a little simplistic — sounds like it could run into the same sorts of problems the current system causes;

What about simply abstracting that design over versions?

module.exports = {
   config: { … },
   plugins: [ … ],

   betaConfig: { … },
   betaPlugins: { … },

   canaryConfig: { … },
   canaryPlugins: { … }
}

… where exports.config corresponds to the app named Hyper.app, exports.betaConfig corresponds to a version named Hyper Beta.app, exports.flippityConfig corresponds to Hyper Flippity.app, etc. This leaves the mechanism extensible to whatever someone may need to do — whether it's a user trying out the Canary channel, or a plugin-developer bisecting a particular bug in his code down to the Hyper releases that cause it.

Whaddya think? (=

---

Oh, and a quick aside re: the “default” config applying to all — tbh, I think that's a red herring! Y'all made the config-file an evaluated Node module for a reason, no? So that you could do more powerful stuff?

const commonConfig = {
   windowSize: [960, 540],
   fontFamily: '"Input Nerd Font", Knack, Menlo, "DejaVu Sans Mono", '
      + 'Consolas, "Lucida Console", monospace',
}

module.exports = {
   config: Object.extend({}, commonConfig, {
      base16: { scheme: 'eighties' }
   }),

   canaryConfig: Object.extend({}, commonConfig, {
      base16: { scheme: 'bright' }
   }),
}

Boom, my Canary uses a bright colourscheme, to remind me which app I've opened. No need for explicit support by Hyper (although including such an example in the documentation would be 👌💯!

[ELLIOTTCABLE]

(Although I think it'd be eminently reasonable for the Canary-channel downloadable artifacts to do a one-time initial setup, adding a line like module.exports.blahConfig = Object.extend({}, module.exports.config) to the user's config-file, thus sharing the config by default)