Use a Universal Module Definition

[kohenkatz]

I want to get input before I actually make such a big change.

Here are the benefits:

• Allows use of Browserify with Bower. (Bower previously used wildemitter-bare.js which is not compatible with Browserify.)
• Allows use of AMD loaders like require.js
• Removes the need for separate wildemitter.js and wildemitter-bare.js files.

This should not affect anyone who is already using a NodeJS or CommonJS inclusion, which will still work the same way they always did.

[HenrikJoreteg]

Hi @kohenkatz! you're awesome. Conceptually having a UMD build is fine.

If I had my little way, however, I'd prefer the source was an ES6 module and then we have an npm run build that kicks our a lib directory that works for node and potentially we could kick out a UMD compatible build there too if you think we should support it.

Having the raw source as an ES6 module seems optimal because ES6's module's lack of support for dynamic requires allow some really cool build optimizations.

I'm of the opinion that both AMD and bower are on the decline, so I'm totally ok not supporting them directly. /me shrugs

For an example of a project set up like what I'm talking about see: reactjs/reselect (note the compile script in package.json) the src directory is checked in the lib gets generated pre-publish and published to npm.

Having said all of this... do as you wish :) You could leave it this way too. Just be sure to bump the major version when you publish to npm.

[kohenkatz]

@HenrikJoreteg I had thought of doing an ES6 module with a build step. I completely agree with you about the great benefits of ES6 modules.

That said, I haven't found a good way to implement the "Mixin" feature in an ES6 module. If we don't care about that, then an ES6 module (and using simple class inheritance class MyClass extends WildEmitter) is the way to go.

Given that the whole reason I got involved in this project in the first place was to help implement the "Mixin" feature in order to simulate multiple inheritance, I don't want to take that feature away.

In any case, UMD is definitely an intermediate step towards a real ES6 module, which I will see if I can figure out how to implement.

[HenrikJoreteg]

so, just one clarification, I don't think we need to make this an ES6 class (not a huge fan of those, personally) i think it's totally fine in terms of how it's structured I just mean using ES6 modules to export

// define it however
const WildEmitter = 

// use ES6 module syntax to export
export default WildEmitter

[kohenkatz]

OK, I'll do a new PR for that instead of merging this one.