You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is pretty obvious from all the explanations that can be found online that the best and only solution for the conflicts between zone.js and core-js Promise polyfills is to ALWAYS load core-js before zone.js.
However, sometimes the applications need to run in hostile environments where container applications or other contained applicatons might be using zone.js + Angular and might be loaded before. Order just can't be controlled and requiring changes from other teams is a pain. If there were opportunities to coordinate with other teams to always load core-js Promise polyfill along with their Angular, we should be good. However, sometimes this is not an option or it is an option that require too much effort.
Up until core-js 3.11.0, the conflict could be solved by saving the previous value of the global Promise (already patched by zone.js) and restore it after the code bundle containing core-js has been processed, thus preventing impact on any other application relying on that patched Promise.
From 3.11.1 onwards, I can see there has been a good amount of changes to es.promise.js. Don't know exactly which one, but at least one of these changes is causing breakages in IE11 in environments where apps with zone and core-js need to coexist.
Zone.js is doing this:
var ZONE_AWARE_PROMISE_TO_STRING = 'function ZoneAwarePromise() { [native code] }'; ... ZoneAwarePromise.toString = function () { return ZONE_AWARE_PROMISE_TO_STRING; };
Because of the statement above, core-js is moving out of the detection routine here (es.promise.js, line 68):
if (V8_VERSION >= 51 && /native code/.test(PromiseConstructor)) return false;
Even if the regular answer should be "go find a way to guarantee core-js is loaded before zone", would the devs consider to think on any kind of trick that could prevent the breakages that can be perceived?
Our current solutions are:
Downgrade core-js to 3.11.0
Add some ugly trick to deviate the flow and avoid the breakage, like the snippet below:
It is pretty obvious from all the explanations that can be found online that the best and only solution for the conflicts between zone.js and core-js Promise polyfills is to ALWAYS load core-js before zone.js.
However, sometimes the applications need to run in hostile environments where container applications or other contained applicatons might be using zone.js + Angular and might be loaded before. Order just can't be controlled and requiring changes from other teams is a pain. If there were opportunities to coordinate with other teams to always load core-js Promise polyfill along with their Angular, we should be good. However, sometimes this is not an option or it is an option that require too much effort.
Up until core-js 3.11.0, the conflict could be solved by saving the previous value of the global Promise (already patched by zone.js) and restore it after the code bundle containing core-js has been processed, thus preventing impact on any other application relying on that patched Promise.
From 3.11.1 onwards, I can see there has been a good amount of changes to es.promise.js. Don't know exactly which one, but at least one of these changes is causing breakages in IE11 in environments where apps with zone and core-js need to coexist.
Zone.js is doing this:
var ZONE_AWARE_PROMISE_TO_STRING = 'function ZoneAwarePromise() { [native code] }';
...
ZoneAwarePromise.toString = function () { return ZONE_AWARE_PROMISE_TO_STRING; };
Because of the statement above, core-js is moving out of the detection routine here (es.promise.js, line 68):
if (V8_VERSION >= 51 && /native code/.test(PromiseConstructor)) return false;
Even if the regular answer should be "go find a way to guarantee core-js is loaded before zone", would the devs consider to think on any kind of trick that could prevent the breakages that can be perceived?
Our current solutions are:
window.Promise.toString = function() { return Function.toString.call(window.Promise); }
One alternative that could avoid the current breakage is to change that line from the detection routine to:
if (V8_VERSION >= 51 && /native code/.test(inspectSource(PromiseConstructor))) return false;
Thanks for your attention.
The text was updated successfully, but these errors were encountered: