SPFX Polyfill Out of Stack Space exception

[ArcanDotNet]

Category

• Question
• Typo
• Bug
• Additional article idea

Expected or Desired Behavior

Importing ES6-Shim or Core.js/ES6 Shims for ES6 library support in SPFX.

Any suggestions as to how to integrate the necessary Polyfills into SPFX in general would be greatly appreciated. I have tried manually adding Polyfills for each issue but the existing libraries are thousands of lines long and have required years to develop. Recreating this functionality from scratch would be an exhaustive effort.

As a large share of modern libraries rely on ES6 and its polyfills. This issue greatly limits developer options. Angular 2+ and many other solutions require this functionality.

Observed Behavior

Polyfill libraries (ES6-Shim and Core.JS/ES6) work in other TypeScript based deployment scenarios, but throw 'Out of Stack Space' errors in SPFX.

https://github.com/paulmillr/es6-shim
https://github.com/zloirock/core-js

So far in my testing I've got the error down to these 2 polyfills. All of the other Angular requirements will load without issue.
import 'core-js/es6/map';
import 'core-js/es7/reflect';

map is the only Angular 2 requirement that's causing an issue in SPFX and the SP Loader has it's own map implementation for IE.

I have tracked the issue most of the way down into the sp-loader-assembly_en-us.js file on line 703 where it seems to rerun this loop until it crashes:

var queue = new Array(1000);
function flush() {
  for (var i = 0; i < len; i += 2) {
    var callback = queue[i];
    var arg = queue[i + 1];

    callback(arg);

    queue[i] = undefined;
    queue[i + 1] = undefined;
  }
  len = 0;
}

It also pops in and out of the eval in block 37 while it goes through this loop:

/* 37 */
/***/ (function(module, exports) {

(function (global) {
  eval('/*\r\n * SystemJS v0.19.25......................................');
}.call(exports, (function() { return this; }())))

I have tried to step through the code until it finally dies but so far I haven't been able to track it that far. My thoughts at the moment are that this is a collision of type 'Map' which is defined globally in the SP-Loader and in the Core-JS polyfills.

sp-loader-assembly_en-us.js
if (typeof Map == 'undefined' || typeof((new Map).values) !== 'function' || !(new Map).values().next) { exports.Map = createCollection({ // WeakMap#delete(key:void*):boolean 'delete': sharedDelete, //:was Map#get(key:void*[, d3fault:void*]):void* // Map#has(key:void*):boolean has: mapHas, // Map#get(key:void*):boolean get: sharedGet, // Map#set(key:void*, value:void*):void set: sharedSet, // Map#keys(void):Iterator keys: sharedKeys, // Map#values(void):Iterator values: sharedValues, // Map#entries(void):Iterator entries: mapEntries, // Map#forEach(callback:Function, context:void*):void ==> callback.call(context, key, value, mapObject) === not in specs forEach: sharedForEach, // Map#clear(): clear: sharedClear }); }

map.js
require('../modules/es6.object.to-string'); require('../modules/es6.string.iterator'); require('../modules/web.dom.iterable'); require('../modules/es6.map'); module.exports = require('../modules/_core').Map;

If you console.log Map before you import the core-js map implementation in your webpart file, it will spit out the createCollection function. Once you've imported core-js/es6/map your next console.log will never finish because of an out of stack space exception.

This issue has been noted here as well, though the relation to polyfills only was not noticed:

angular/zone.js#316
BenGWeeks/sp-dev-fx-webparts#1

Steps to Reproduce

Yo @Microsoft/SharePoint a new solution and add either ES6 Polyfill to your code, run a gulp serve and try to use it in Internet Explorer.

[NickSevens]

Hi @ArcanDotNet did you find any way to fix this? We're facing the same issue, in IE11 indeed.
Thanks

[ArcanDotNet]

So I came up with a workaround-ish. I am by no means advocating this as a proper solution, but it does resolve the problem.

SP-Loader defines a global object named 'Map' which is an ES6 standard they are essentially polyfilling. In SPFX v1.3 this happens in sp-loader-assembly_en-us.js.

After an exhaustive amount of debugging and trying various things I tried logging the value of map, and eventually undefining it in my web part code just before I load the proper core-js polyfill for the same ES6 standard. By this point in the SP-Loader lifecycle, it seems replacing the existing Map function with the core-js implementation does not break SPFX and the web part will load.

import 'core-js/es6/symbol';
import 'core-js/es6/object';
import 'core-js/es6/function';
import 'core-js/es6/parse-int';
import 'core-js/es6/parse-float';
import 'core-js/es6/number';
import 'core-js/es6/math';
import 'core-js/es6/string';
import 'core-js/es6/date';
import 'core-js/es6/array';
import 'core-js/es6/regexp';
import 'core-js/es6/weak-map';

// Check for native support of Map vs Polyfill
if(Map.toString().indexOf('function Map()') === -1)
{
     Map = undefined;
}
import 'core-js/es6/map';
import 'core-js/es6/set';
import 'core-js/es6/reflect';

A proper resolution to this issue would be for SPFX to import core-js polyfills for the sp-loader or something of the like. The current Map implementation that's defined in the loader and handed down to the rest of the web part does not meet the specification.

[octogonz]

+@VesaJuvonen

[NickSevens]

@ArcanDotNet indeed, the Map object inside es6-shim seemed to be the cause with us. Thanks for the pointers!

[pedro-pedrosa]

The default (SP-Loader) implementation of the Map object breaks when you use it with other core-js polyfills (such as Array.from), hence the need to use Map from core-js as well.

This work around definitely saved me a lot of time, thank you for investigating.

[javierordonezcastro]

Did someone find a solution?

I tried what @ArcanDotNet indicated but it did not work. I suppose that the incompatibility in my case comes from another object different from the "Map"

Thank you very much in advance,
Javier

[octogonz]

Polyfills are global and affect all components on the page. Although I understand the motivation here, a third-party component really should not be loading polyfills. Even if it doesn't break today (as seen above), it may break with some future SPFx update or in some other context that wasn't tested (e.g. classic pages or a mobile app).

The sp-polyfills package was designed to be very conservative for performance reasons, since it is guaranteed to be loaded on every page where SPFx runs. In some cases the footprint may be very important, e.g. because the page is shared with a legacy application's scripts. We even discourage first-party developers from loading custom polyfills because it complicates the test matrix and third-party environment for each page.

If there is a community need for heavyweight polyfills, the right solution would be to create a separate package (e.g. sp-expensive-polyfills) that a web part can depend on. Then it would be loaded only if such a web part is present on the page. This would be a feature request for SPFx.

That said, if you can find some workaround that seems to work, you're free to use that approach as long as you're okay with the risks involved.

[octogonz]

@patmill fyi