Is worth a noConflict method?

[irbian]

Hi!

This is probably something unneeded with the last ES6 structure, but I´ll expose it here just in case.

We are using the bundled version inside an IIF and we found that MooTools have a broken implementation that core-js overwrite, provoking that later code outside our library breaks because it expects the MooTool version

Now, one options would be to change the scripts order, but as our library it´s meant to be dropable without our control, we can´t assume that

We can´t just use the broken Array.from version, so...

Would a noConflict method would be feasible? Something that allow us to restore the global space to the state before the polyfills were applied

I have found related #1034 but I think I found more

Rereading the docs, I guess that this behaviour is explained here "That means that core-js checks if a feature is available and works correctly or not and if it has no problems, core-js use native implementation.", but maybe it would be better to add something like "This means that third party method implementations not coded properly won´t work next to core-js (Google Maps, MooTools..)"

[zloirock]

Hi @irbian. I thought about a .noConflict method for a long time, but I decided that it make no sense - it will cause more problems than it will solve.

Most likely, for your case, you could use this https://github.com/zloirock/core-js#configurable-level-of-aggressiveness or the pure core-js version.

However, it's better to get rid of MooTools ASAP since sooner or later other of your dependencies will use native, incompatible with MooTools, versions of those methods.

but maybe it would be better to add something like

I think that it's already implied.

[irbian]

Most likely, for your case, you could use this https://github.com/zloirock/core-js#configurable-level-of-aggressiveness or the pure core-js version.

We have yet to move to ES6 this project

However, it's better to get rid of MooTools ASAP since sooner or later other of your dependencies will use native, incompatible with MooTools, versions of those methods.

Oh, I agree that much, but we don´t choose where the clients drop us :D this is a library so we can´t control that

I think that it's already implied.

It is! and it's a problem that happened on several issues so is not so difficult to find it, but I would have found it helpful to see it there

Thanks for your answer!

[zloirock]

Oh, I agree that much, but we don´t choose where the clients drop us :D this is a library so we can´t control that

The pure core-js version is the proper option for cases like yours.

[irbian]

Can be bundlified?

[zloirock]

Sure. For injecting it automatically, you could use Babel.