Build for UMD

[bates64]

Via the --standalone browserify option.
Fixes #537. Note that the export is window.choo.

Only caveat is the choo/html is not exported -- the best way to do this would probably be to export choo.html, but that'd require changes to the source also - see heyitsmeuralex/nanochoo for a potential solution to this (evicting choo/html altogether as it is unused within the choo source).

[bcomnes]

https://github.com/choojs/choo-umd existed to do this, but what is your use case? I'm more 👎 on UMDs than I ever have been.

EDIT: I've softened up on them since writing the above. People should till be bundling but we can still support this path.

[bates64]

Via @arturi:

This functionality is actually useful for quick demos and taking a library for a spin, build step is good for production, but shouldn’t be required for starting out.

Here’s an example of someone wanting to use Choo without build-steps: https://twitter.com/louiscenter/status/950312739825647616.

I'd note that this has little-to-no impact on the build size and changes nothing other than allowing one to include choo in a script tag, which I'd argue is a great thing 🎉 There's no extra file generated, etc, etc.

[toddself]

We never actually use choo/html since choo isn't a dependency of most of our codebase -- rather we install and require bel directly.

This is something I'd love to do in the next release of choo -- xhr was already dropped; I don't feel there is a significant advantage gain to including bel.

[bates64]

For reference, I saw significant gains (well, losses) evicting both nanorouter (which is easy enough to re-implement) and choo/html.

[goto-bus-stop]

i think we should drop choo-umd and instead only have this

[YerkoPalma]

Would this cause conflicts when using choo-devtools? Since both exports a choo object to window?

[yoshuawuyts]

@YerkoPalma yeah, it would. Might need to alias choo before importing devtools. Maybe we should alias devtools if it already detects a globl choo instance. A PR for that would be very welcome!

[goto-bus-stop]

I guess we could uppercase Choo here?

[YerkoPalma]

I prefer uppercasing choo (Choo) instead of aliasing. Now I wonder how views would be built with umd, since bel is not expose and has no umd build, that's the only concern I have about it.

[bates64]

@YerkoPalma I'm still advocating evicting bel from choo as in nanochoo. However, we could export:

window.Choo = { choo, html, devtools }

with devtools extending Choo if it already exists

[YerkoPalma]

Could this be uppercased to Choo to avoid issues with devtools?

[goto-bus-stop]

@heyitsmeuralex do you have time to address @YerkoPalma's review soon? i can do it too if not.

[goto-bus-stop]

This will add choo/html to yo-yoified browserify bundles too, increasing bundle size by a few KB… I think people should probably use nanohtml directly instead for UMD, or we could have a separate UMD entry file that does something like

module.exports = require('./')
module.exports.html = require('./html')
module.exports.raw = require('./html/raw')

[bates64]

Good point. Reverting.

was addressed