I'm against introducing a new tool (i.e. WebPack), especially for UMD. In the next version we'll use Babel and to address UMD there's a specific plugin: ES2015 modules to UMD transform.

I would agree with you if the UMD wrapper was only benefit gained by adding webpack to the build chain, but webpack actually serves many purposes. (And it's easy to add babel to webpack)

• It provides the UMD wrapper
• It allows our dependencies (such as axios and js-base64) to be easily packaged for the web (or not they can be marked as external and then users can provide them if they want).
• It allows the library to be cleanly decomposed into smaller modules.
• It isolates the modules from: 1) 3rd party code 2) the each other

Decomposing the library results in more understandable code and a codebase that is easier to search.

• All of the API objects now subclass Requestable to get their http behavior instead of using the random function _request() which is defined way above as var _request = Github._request = function _request
• You don't have to skim through one source file to find Repository you can just go to lib/Repository.js

Hi @clayreimann. Thank you for your reply.

• It provides the UMD wrapper
  Doable with Babel

It allows our dependencies (such as axios and js-base64) to be easily packaged for the web (or not they can be marked as external and then users can provide them if they want).

If you mean to create a package containing everything needed, we aren't doing this. Personally I'd be against it but I'd love to have some thoughts from @Aendrew and @alexcanessa. By the way, this could be done with Browserify and its standalone property.

• It allows the library to be cleanly decomposed into smaller modules.

ES6 allows that

• It isolates the modules from: 1) 3rd party code 2) the each other

ES6 allows that

Decomposing the library results in more understandable code and a codebase that is easier to search.

• All of the API objects now subclass Requestable to get their http behavior instead of using the random function _request() which is defined way above as var _request = Github._request = function _request
• You don't have to skim through one source file to find Repository you can just go to lib/Repository.js

Totally agree on that. I'm working on a project that extends the functionality of this library and it's a bit of a PITA. I had to create some weird workarounds. Said that, all this modularity can be achieved with ES6 natively.

In conclusion I still don't see the need for a complete new build tool (we've still Gulp in place) for such simple project but I'm open to further this discuss this.

@AurelioDeRosa Maybe we're talking past each other, so let me lay out the assumptions that I'm working under and what I thought the goals are.

I thought:

1. The desired result of the build process was to produce a file github.min.js that can be used as-is in the browser, node, or a require environment.
2. Babel didn't have a polyfill for the module loader yet

In regards to your assertion:

If you mean to create a package containing everything needed, we aren't doing this.

This actually is the current state of affairs if you look at lines 17-37 you can see that where applicable the missing bits are getting requireed into the core library.

That being said it would appear that Babel does have a polyfill for module loader and as such I'll investigate that. If it looks like it will do what we need (namely get all the objects from lib/ into github.js then great. Otherwise I still think we need something like webpack or browserify to produce a web-compatible output. (corollary if we need webpack or it's ilk we'll probably also want to add a browser property to package.json)