Babel doesn't add ES6 polyfills

[semireg]

Thank you for this amazing project. I'm successfully running JS Interpreter + Babel to create a very nice scripting environment for my Electron app's user-supplied JS. I have a very good grasp on the JS-Interpreter docs, setProperty, createNativeFunction, etc. I've taken all the examples and turned them into my own unit tests to make sure I understand how they work. This stuff is nothing short of amazing.

Even though I have ES6 syntax capabilities via Babel, one thing I'm stuck on is how to handle missing Array.prototype.findIndex. I feel like I'm missing something.

I know I could add them as native functions, which seems like overkill. I know I can add them inline by prepending the text of a polyfill to the user-supplied JS, but this might be inefficient and it affects line numbers.

Is there a way to "preload" or patch the environment? Is this a job for serialization? Something else entirely?

[NeilFraser]

Ok, that's a real problem. Babel (at least as run in JS-Interpreter's Babel demo) is not providing the required polyfills. That's completely against the purpose it is intended to serve.

I'm about to get on a flight, so I don't have time to look at this right now. However, if you'd like to take a stab at it and figure out how to get Babel to generate polyfills, that would be amazing. This looks like a good starting point: https://karen-kua.medium.com/the-end-of-babel-polyfill-the-more-efficient-alternative-95f959fef9c2

You can test it with

alert(Math.sign(-8));

Babel should create a polyfill for Math.sign (and only that polyfill).

[semireg]

In my earlier testing I was "successful" at getting babel to polyfill, but it does it by requiring the core-js modules, and not by inlining the actual code.

Babel transform:

    const { code } = transform(this.js, {
      presets: [['env', { debug: true, useBuiltIns: 'usage', corejs: '3.37' }]]
    });

Results in...

      "use strict";
      
      require("core-js/modules/es.error.cause.js");
      require("core-js/modules/es.error.to-string.js");
      require("core-js/modules/es.array.find.js");
      require("core-js/modules/es.array.find-index.js");
      require("core-js/modules/es.object.to-string.js");

This points to me having to use a bundler to get them into a single file, which brought me back to my original idea of a "preload" because conceptually it might be cleaner by: 1) avoiding source maps and, 2) being explicit in the JS Interpreter's "polyfilled env" that's being setup.

From an outsider perspective (dev UX), it might be nice to have something like this daydreamed API:

Interpreter([preloadJS, userJS], initFunc);

Entry would start at the beginning of the array. Each element would be executed in the same global env, but parse/runtime errors would be generated with line numbers relative to their own element's code. I don't have the mental map to know if this is even the right path. Please forgive my naivety. 😉

[jsProj]

From an outsider perspective (dev UX), it might be nice to have something like this daydreamed API:

Interpreter([preloadJS, userJS], initFunc);

I modified it to use my own provided API:

// AcornRuntime;
let rt = new AcornRuntime({ // - modified constructor
    // not async, just handy init callback, preserving JSI initFunc
    onInit: function (rt, rt.rtGlobal) { console.log("ready"); },
});
const ps_console = rt.nativeToPseudo({ log: console.log });
rt.setProperty(rt.rtGlobal, "console", ps_console);
rt.execute(`console.log("started"); for (var i = 0; i < 1000; i++) console.log(i);`); // .execute() - custom
setTimeout(function () { rt.stop(); }, 1000); // .stop() - custom
rt.start(); // .start() - custom