Break es6-shim into smaller, independent submodules

[appsforartists]

Libraries like prfun (incidentally recommended in the es6-shim README) augment the Promise prototype with additional methods. Promise.promisify is particularly nice.

I just tried incorporating the es6-shim into my Node 0.11.13 project to get access to the Array polyfills. Now, I'm getting Promise.promisify cannot be found errors. A quick skim through the shim source shows that es6-shim completely overwrites the global Promise object with its own polyfill when it isn't satisfied with the present implementation.

I could probably work around this by including es6-shim before prfun, but the library that includes prfun and the one that includes es6-shim have nothing to do with each other. It'd be a shame to introduce a needless dependency to work around this.

[appsforartists]

The most sane solution could be modularizing the shim and using something like webpack to make a browser-distributable library. Then, someone who only needs "es6-shim/arrayPrototype" can require("es6-shim/arrayPrototype") without breaking code that has nothing to do with Arrays. People targeting the browser can still load the whole es6-shim distribution, you'd just use webpack to build it.

[ljharb]

We definitely shouldn't be recommending something that modifies globals in a non-spec-compliant way, that's insanity. I'll fix the README, thanks.

The problem here is prfun, not es6-shim - if you choose to use something that modifies globals in a non-spec-compliant way, all bets are off.

[appsforartists]

I understand the reluctance to recommend a project that muxes global objects, but that's not the issue here.

The issue is that ES6 Shim has a huge footprint and isn't distributed in a modular way. If you use one library that needs a small part of ES6 Shim (that's unrelated to promises), and another library that depends on something like prfun, you can end up with race conditions that break the app.

How do you feel about supporting require("es6-shim/array") or require("es6-shim/promise") as an alternative to the monolithic require("es6-shim")?

[ljharb]

#136 covers that somewhat.

That's not a bad approach, but it would mean we'd need to incorporate browserify in as a build step, and we'd need to build both minified and unminified versions of files each release.

[cscott]

As the author of prfun, I agree the problem if any is in prfun. But I don't
fully understand what is happening, since prfun will require('es6-shim')
before adding its methods. I suggest opening a bug against prfun and we
can investigate.

I don't think the mention of prfun in es6-shim is inappropriate -- unlike
other promise libraries, prfun is explicitly written to be loaded on top
of a es6-compliant promise implementation.

[appsforartists]

@cscott I don't know if it's worth fixing. The problem is that you augment native Promises, then es6-shim declares them insufficient and replaces them with its polyfill. Then, when the code that relied on prfun runs, it errors, because prfun was effectively uninstalled when es6-shim replaced the native implementation.

As long as both es6-shim and prfun seek to modify the global Promise, conflicts are inevitable.

[cscott]

@appsforartists please open a bug against prfun. prfun can use the same "is the promise insufficient" test that es6-shim uses. Alternatively, you can explicitly ask prfun to use es6-shim's promises, that's in the README.

[chrishyle]

👍

[paulmillr]

Why don't you just use individual shims?

[zloirock]

@paulmillr total size and compatibility? For example, Array.from individual shim not support iterators, which makes it almost useless.
P.S. core-js supports custom build and is split to commonjs submodules :)