Expose nanobus

[trygve-lie]

Not sure if this is a wanted feature, but here we go.

Currenty bel is exposed so one can import it by choo/html. This expoes nanobus in the same way on choo/ee.

Main reason for this is that there are many places one would benefit from using an event emitter to do stuff in an application where the code is not directly bound to choo but the code lives among choo (example of such code can be code doing operations on a map).

If one have such, its desirable to be able to use the same event emitter, and version, as bundeled in choo to reduce the final bundle size. By being able to get hold of the event emitter in choo like this one will be a bit more safeguarded on this.

[bcomnes]

I was also thinking about exposing nanocomorph. There might be value in ensuring a consistent module version of some of the ingredients like bel, nanobus and nanomnorph.

[toddself]

Perhaps naïvely i just rely on npm to resolve this for me. we use nanobus in a lot of our friend end and since npm 3 > dedupes on install we just install it along side.

Also a lot of our components don't rely on choo directly. we install bel and nanobus since those are the components being used.

I'm not against this pr though

[yoshuawuyts]

On vacation rn so I'll keep it short. Think I'd probably just rely on importing it from npm because through deduping it means you'll only have one copy anyway. Bel is exposed b/c its required for choo to work as intended, exposing nanobus isn't the case for that. Were using 10 or so deps, exposing them seems a bit like clutter imho. I know it's a small change, but I don't think we should merge this.

…

On Tue, Jul 25, 2017, 18:10 Todd Kennedy ***@***.***> wrote: Perhaps naïvely i just rely on npm to resolve this for me. we use nanobus in a lot of our friend end and since npm 3 > dedupes on install we just install it along side. Also a lot of our components don't rely on choo directly. we install bel and nanobus since those are the components being used. I'm not against this pr though — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#536 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWlei5F2aFCFLxXxyLxvjbtdNsfZFxSks5sRhNdgaJpZM4OiVj6> .

[bcomnes]

I don't have strong feelings either way.

[ungoldman]

Hello! I have three thoughts on this:

1. There's been discussion about possibly removing bel as a dependency to avoid the choo/? require pattern and reduce dependencies (see Build for UMD #617). I'd argue it's probably best to reduce the number of require endpoints dependent on file organization (preferably to zero), rather than create another one.

2. The instance of nanobus used by choo is currently exposed as choo.emitter -- while I understand the motivation to want to use the same nanobus module for other tasks to reduce bundle sizes, complicating choo's API might not be a price worth paying. Ensuring the nanobus version you're using is same as choo's and relying on npm to dedupe seems like a better strategy to me.

3. If it seems like a good idea to expose some of choo's tools to users, I would prefer to expose them via module.exports, as it makes it less easy to introduce a breaking change by reorganizing or renaming files.