A Map polyfill until it's native

[WebReflection]

Is your feature request related to a problem? Please describe

For interoperability reasons, I'd like to have Map available (Set coming after if this works well).

Describe the solution you'd like

Imagine this map.js file is all we need to have import Map from './compat/map.js'; around, followed by a globalThis.Map ??= Map; after.

const iterator = Symbol.iterator;
const setPrototypeOf = Object.setPrototypeOf;

let Map = globalThis.Map;

if (!Map) {
  Map = function Map(iterable) {
    const keys = [];
    const values = [];
    const map = setPrototypeOf(
      {
        clear() {
          keys.length = 0;
          values.length = 0;
        },
        delete(key) {
          const i = keys.indexOf(key);
          if (i < 0) return false;
          keys.splice(i, 1);
          values.splice(i, 1);
          return true;
        },
        entries() {
          return map[iterator]();
        },
        forEach(callback) {
          for (let i = 0; i < keys.length; i++)
            callback(values[i], keys[i], map);
        },
        get(key) {
          const i = keys.indexOf(key);
          return i < 0 ? undefined : values[i];
        },
        getOrInsert(key, defaultValue) {
          const i = keys.indexOf(key);
          return -1 < i ? values[i] : (values[keys.push(key) - 1] = defaultValue);
        },
        getOrInsertComputed(key, callback) {
          const i = keys.indexOf(key);
          return -1 < i ? values[i] : (values[keys.push(key) - 1] = callback(key));
        },
        has(key) {
          return -1 < keys.indexOf(key);
        },
        keys() {
          return keys[iterator]();
        },
        set(key, value) {
          let i = keys.indexOf(key);
          if (i < 0) i = keys.push(key) - 1;
          values[i] = value;
          return map;
        },
        values() {
          return values[iterator]();
        },
        get size() {
          return keys.length;
        },
        [iterator]() {
          const iterable = [];
          for (let i = 0; i < keys.length; i++)
            iterable.push([keys[i], values[i]]);
          return iterable[iterator]();
        },
      },
      Map.prototype,
    );
    if (iterable) {
      const g = iterable[iterator]();
      do {
        const c = g.next();
        if (c.done) break;
        const entry = c.value;
        map.set(entry[0], entry[1]);
      } while (true);
    }
    return map;
  };
  
  Map.groupBy = function(iterable, callback) {
    const map = new Map;
    const values = [];
    const g = iterable[iterator]();
    do {
      const c = g.next();
      if (c.done) break;
      const value = c.value;
      const key = callback(value);
      map.getOrInsert(key, values).push(value);
    } while (true);
    return map;
  };
}

export default Map;

Describe alternatives you've considered

I haven't looked into the core of this project but:

• I love it already!
• I've been writing Web polyfills for 25+ years at this point
• I'd like to help this move forward with Web compat as I can (and when I can, of course)

Additional context

Common polyfills will not work in here because there are too many constraints around what is still accepted in common JS and what is just not possible in here.

My polyfill experience is all about that, meaning I can write ad-hoc code working around common/modern APIs constraints, so here my first contribution because without Map I believe this is a no-go for tons of possibly working solutions out of the biggest PL ecosystem out there, and this is a Web related project too 🥰

[WebReflection]

Tests I have run against, if anyone is interested:

import Map from "./map.js";

console.log(
  new Map([[1, 2], [3, 4]]) instanceof Map
);

console.log(new Map([[1, 2], [3, 4]]).size);
console.log(new Map([[1, 2], [3, 4]]).get(1));
console.log(new Map([[1, 2], [3, 4]]).get(3));
console.log(new Map([[1, 2], [3, 4]]).delete(3));
console.log(new Map([[1, 2], [3, 4]]).delete(2));
new Map([[1, 2], [3, 4]]).forEach(function (v, k, m) {
  console.log(v, k, m);
});

const map = new Map();
console.log(map.getOrInsert(1, 2));
console.log(map.size);
console.log(map.getOrInsertComputed(3, () => 4));
console.log(map.size);

console.log(map.entries());

// console.log(new Map([[1, 2]]).keys().next());
// console.log(new Map([[1, 2]]).values().next());

const inventory = [
  { name: "asparagus", type: "vegetables", quantity: 9 },
  { name: "bananas", type: "fruit", quantity: 5 },
  { name: "goat", type: "meat", quantity: 23 },
  { name: "cherries", type: "fruit", quantity: 12 },
  { name: "fish", type: "meat", quantity: 22 },
];

const restock = { restock: true };
const sufficient = { restock: false };
const result = Map.groupBy(inventory, item =>
  item.quantity < 6 ? restock : sufficient,
);
console.log(result.get(restock));

[WebReflection]

to whom it might concern:

• njs does not support classes, yet supports new syntax, and that's OK
• njs doesn't work with prototype pollution, really ... because ...
• njs does not support this, not in methods, not via callback.call/apply, nothing
• njs does not support function generators, but it was a smart move to support iterables (and all arrays are)
• everything else was a try and fail procedure, njs -m for testing modules is a great primitive!

what else doesn't njs support I have learned the hard way?

• array spread is fine, objects destructuring is not ... it also shows a weird unrelated error, try const { setPrototypeOf } = Object and read "setPrototypeOf is not supported" ... misleading, it's the syntax that is not
• when this is used arbitrarily, such as const ctx = thisArg ?? this; it throws an unrelated error about something being addressed before being initialized

I can workaround all the current gotchas though, yet I cannot please the modern JS syntax in all its scenarios, but I think that's OK, althought objects destructuring would be already my most favorite/preferred feature to add.

edit

P.S. reason I love this project already is that it indeed drops unnecessary stuff from the language ... this, except in class methods, is overrated, bind and call and apply passing this are also overrated the moment you rarely need to invoke anything with a different context and you never need to bind arguments when arrow functions are around ... it's fresh air out of a very old PL that never got a chance to be better, faster, less error prone, due its contract to never break out there. You folks are nailing it, and as long as it's beter integrated than QuickJS could ever be, I think this project should get all the love it deserves.

Last, but not least, it'd be great to have this env described for AI/LLMs because otherwise editing or writing code is going to be a constant "no, don't do that, it won't work" process, which I had fight against in my IDE (not out of vibe-coding this, out of telling the IDE to stop suggesting stuff that won't work in njs env ... well, you need to know more than your IDE to do that though, hostile to contributors).

[xeioex]

Hi @WebReflection,

We are moving away from njs engine, and stopped doing active development for it.
Instead, we have QuickJS engine available, see here how to enable it.

QuickJS support Map, classes and modern ES2023 features.

[WebReflection]

that's both great to hear, yet I am sorry njs effort faded, yet it's the default and on ArchLinux all I could test.

You need to carefully update the docs around this matter though, because more than a dev told me "they use their own JS which has too poor capabilities" so be aware people want latest JS, yet the sub-par yet wonderful constrains you had there were spot-on to me, nobody needs method.call on the server, that smells like bad architecture already

[xeioex]

@WebReflection

yet it's the default and on ArchLinux all I could test.

we build njs OS packages for these platforms.

Last, but not least, it'd be great to have this env described for AI/LLMs because otherwise editing or writing code is going to be a constant "no, don't do that, it won't work" process,

good idea, what is the best way to distribute this knowledge to AI agents? Plain AGENTS.md with a section on how to write code for njs environment?

[WebReflection]

@xeioex

we build njs OS packages for these platforms.

ArchLinux "is inevitable" (and a great target anyway, AUR will take care of the rest anyway)

what is the best way to distribute this knowledge to AI agents? Plain AGENTS.md with a section on how to write code for njs environment?

the best idea is to remove njs (engine) entirely from your site and docs and just state you are QuickJS based, AI will take over from there. You keep "njs engine" around next round of training data? You're "out"!

[xeioex]

@WebReflection

the best idea is to remove njs (engine) entirely from your site and docs and just state you are QuickJS based, AI will take over from there.

I would love to from maintenance standpoint, but it is complicated.
We have existing users with code for njs engine, qjs works with code written for njs almost fine. In our local repos, I did ~10lines fixes, but it is still requires some time and effort to debug and fix this in a large codebase; and breaking existing installations after an upgrade is not good. Some users prefer njs (for smaller memory footprint).
So, we cannot just disable it right away. But, I plan to make qjs a default engine.

[WebReflection]

…or to simplify, add deprecated around any mention of njs engine in your docs, that’s an easy PR to take care of

[WebReflection]

njs is awesome, reason I’ve spent time to touch base around it. If it’s dead already, I won’t look at it anymore, if it’s not, because people loved it for the right reasons it’s lovely, I’m here to keep it alive and better. It’s your call, not mine 👋

[xeioex]

@WebReflection

If it’s dead already, I won’t look at it anymore,

It is far from dead as a project, we are actively developing nginx-level features. We are just retiring njs JS engine.
The whole idea of retiring engine is to reallocate time to nginx level fearures, not catching up to JS spec development.
So the module development continues.

[xeioex]

njs does not support classes, yet supports new syntax, and that's OK
njs doesn't work with prototype pollution, really ... because ...
njs does not support this, not in methods, not via callback.call/apply, nothing
njs does not support function generators, but it was a smart move to support iterables (and all arrays are)
everything else was a try and fail procedure, njs -m for testing modules is a great primitive!

njs engine implements mostly ES5.1 (strict mode) with a curated set of ES6+ features — arrow functions, template literals, rest parameters (no destructuring), async/await, Promise, a subset of Symbol, etc. Everything else from ES6+ is out of scope. Full list: compatibility page.