Request: Have a version which exposes only A+ and ES6 features about yaku HOT 19 CLOSED

If you var Promise = require('yaku'), I think that will only expose A+ and ES6 features. Do you mean the npmCDN one?

If you mean Yaku.Symbol, Yaku.speciesConstructor(O, defaultConstructor), etc. These are only a part for the ES6 shim, because Yaku won't shim things like ES6 Symbol for the users, so that the users will have the chance to set their preference, such as use core-js Symbol polyfill. For most use cases, you won't like touch them.

from yaku.

Yep, I mean Yaku.Symbol et al. I believe we have var Promise = require('yaku') via the npmCDN version by this file -- https://npmcdn.com/[email protected]/dist/yaku.browser.global.js

Is Yaku.Symbol in the specification? If it isn't, could we have a version which doesn't have it and instead assumes a global ES6 compliant Symbol (whether that be native or a polyfill)?

from yaku.

If I do that, then the user will be unable to choose the right polyfill.
For instance, IE8 doesn't support Symbol, the user want to polyfill it, the user can do it with Yaku.Symbol = require('core-js/library').Symbol. After then Yaku can take advantage of the polyfilled Symbol. If we don't expose an API, there's no way to control Yaku communication with the outside world. In that case you have to pollute the global environment with the Symbol polyfill before Yaku's initialization.

The reason why Yaku has these extra APIs is because the ES6 spec is somehow incomplete for some edge cases. For example, Promise depends on Symbol to work, in some circumstances we have Promise but we don't have Symbol. How to deal with that is still undocumented, and I hope we could find out a better solution.

from yaku.

But I think I can find a way to get rid of these 2:

• Yaku.unhandledRejection(reason, p)
• Yaku.rejectionHandled(reason, p)

But these 4, I can't find a proper way to eliminate them:

• Yaku.Symbol
• Yaku.speciesConstructor(O, defaultConstructor)
• Yaku.enableLongStackTrace
• Yaku.nextTick

from yaku.

In that case you have to pollute the global environment with the Symbol polyfill before Yaku's initialization.

That is what I am asking for :-) I'm wanting to integrate Yaku into https://polyfill.io as our Promise polyfill. We support dependencies meaning that we would know to polyfill Symbol globally before initialising Yaku.

Here is the PR for switching to Yaku -- Financial-Times/polyfill-service#780

from yaku.

Suppose you are depending on two third libs, one depends on core-js to polyfill Symbol, another one depends on polyfill.io to do that. Which one will finally win the global pollution? If you don't have the full control of how the polyfill works on Yaku, that will really be a mess.

from yaku.

If core-js ran before polyfill.io then polyfill.io would not polyfill Symbol. polyfill.io has a detection script which runs before polyfilling a feature, the Symbol detection script is 'Symbol' in this.

If polyfill.io ran before core-js I don't know what core-js does, hopefully it does feature detection much the same as polyfill.io does as to avoid needlessly overwriting functionality.

from yaku.

And what if the user load the two libs by requirejs asynchronously? Nobody will know who wins.

from yaku.

That is true, I wouldn't recommend loading two polyfill libraries which try and polyfill the same features.

from yaku.

Besides, one thing I want to confirm is that all the extra APIs are class's static methods, and will be called only once through the entire project. Most times users won't know they are even exist.

from yaku.

Perhaps Yaku could have a factory functions which accepts these configuration options and returns a Yaku Class with them applied? This way we won't require static methods added to the class and enable configuration for different Symbol polyfills etc. We could even have it have default configuration which uses global Symbol or something else.

from yaku.

Well, if you insist, I will try my best to figure it out. To have a factory will increase a lot of dirty code. I would rather to make a separate version of the core.

from yaku.

Thanks for taking the time to listen to my feature request :-)

I'd rather a separate version of core as well, factories are something I'm not particularly fond of.

from yaku.

I added a new branch yaku.core, I'm not sure if it is ready to be published. So we should checkout it for some time.

For now only one thing is sure that src/yaku.core.js passed all the basic unit tests.

from yaku.

All the tests pass according to my CI -- https://circleci.com/gh/JakeChampion/yaku/2

from yaku.

v0.16.6 published

If everything goes well for a while, I will document it into the readme.

from yaku.

looks good :-)

from yaku.

https://polyfill.io has been using this since August 7th as our Promise polyfill, it is in the default set of polyfills given to users which is served million times a day, every day. We've had no bug reports about this polyfill, I think it is safe to close this issue and document this in the readme.

from yaku.

Thanks for your report, the doc was added. If you are also interested in Promise based project, please try these:

• A better promise based fs lib: https://github.com/ysmood/nofs
• A minimal server middleware composer for the future: https://github.com/ysmood/noflow

from yaku.