JSON3 obliterates existing polyfills on window.JSON even when loading as an AMD module about json3 HOT 3 CLOSED

+1

from json3.

Hi @jaxley,

This was actually the default behavior before v3.2.3, but was changed after a lengthy discussion in #14. The problem with reverting to the pre-3.2.3 behavior is this: if RequireJS, curl, or another AMD loader is loaded in conjunction with a third-party script (say, Facebook Connect, which includes JSON 3), the polyfill won't be loaded unless it's specified as a dependency in a define call. As @jdalton explains:

This [the current behavior] is more for the uncontrolled use like when JSON3 is compiled into a widget that's included on a page that happens to also use AMD (so JSON3 used as a global and as an AMD module).

Libraries like jQuery and Lo-Dash mitigate this by exporting a global even if an AMD loader is present. Both libraries also provide a noConflict function, so the global can be removed if desired. Unfortunately, because JSON 3 is a polyfill that can extend the native JSON object, I'm wary of providing similar functionality—JSON.noConflict isn't a standard method. Another solution would be to expose a global JSON3 object, perhaps with an install or runInContext method. What do you think?

Edit: es-shims/es5-shim#167 is a compelling argument for why deferred execution with a module loader is undesirable.

from json3.

Closed via c05062. See #50.

from json3.