Polyfill too, or just ponyfill?

[jcbhmr]

Is this package intended to be both a polyfill and a ponyfill, or just a ponyfill? I like isomorphic polyfills, but that's just personal preference.

// Should this polyfill globally, or just export 'Worker'?
import "whatwg-worker"

// This seems like a good idea.
import Worker from "whatwg-worker/ponyfill.js"
// OR depending on your preference:
import { Worker } from "whatwg-worker/ponyfill.js"

// This also seems like a good idea (to me). This wasn't part of the original developit/web-worker package though...
import "whatwg-worker/polyfill.js"

[jcbhmr]

Note that the polyfill could just be a complete no-op when imported and bundled for a browser environment 👍

// package.json
{
  "exports": {
    "./polyfill.js": {
      // I am honestly unsure if you need an empty file or if you can just do this
      "browser": "data:text/javascript,",
      "deno": "data:text/javascript,",

      "default": "./polyfill-node.js" // Or whatever filename
    }
  }
}

[jimmywarting]

Creating worker inside of a worker atm is kind of like a polyfill (cuz it gets added to the globalThis atm)

I'm a bit afraid if NodeJS would one day go ahead and implement a spec'ed working web worker.
it seems to be highly requested: nodejs/node#43583 (implement web worker)

Don't really feel like being in any conflict with them if they added it globally

But i'm open for suggestion.
I really would like for browser to just not use my NodeJS specific worker.
So i would like to just export https://github.com/jimmywarting/whatwg-worker/blob/master/browser-worker.js
(that's just a simple export of globalThis.worker)

[jcbhmr]

Here's a basic demo of a possible idea or design pattern thing for polyfill/ponyfill stuff: https://github.com/jcbhmr/html-event-error

// package.json
{
  "imports": {
    "#error-event-polyfill.js": {
      "node": "./dist/error-event-polyfil-node.js",
      "default": "./dist/error-event-polyfill.js"
    }
  },
  "exports": {
    ".": "./dist/index.js",
    "./error-event-polyfill.js": {
      "node": "./dist/error-event-polyfil-node.js",
      "default": "./dist/error-event-polyfill.js"
    },
    "./*.js": "./dist/*.js",
    "./internal/*": null
  },
}

// index.ts
if (typeof ErrorEvent === "undefined") {
  await import("./ErrorEvent-polyfill.js");
}

if (!("onerror" in globalThis)) {
  await import("#error-event-polyfill.js");
}

export {};

// ErrorEvent-polyfill.ts
import ErrorEvent_ from "./ErrorEvent.js";
import ErrorEventInit_ from "./ErrorEventInit.js";

declare global {
  // @ts-ignore
  type ErrorEvent = ErrorEvent_;
  // @ts-ignore
  var ErrorEvent: typeof ErrorEvent_;
  // @ts-ignore
  type ErrorEventInit = ErrorEventInit_;
}

globalThis.ErrorEvent = ErrorEvent_;

The gist is that there's many layers of usage. You can use the author's default feature-detection strategy via the default exported path like this. Sometimes it makes more sense to actually have the default export be the ponyfill version though, particularly when a feature-detect is uncertain because there is no standard implementation. In whatwg-workers maybe we want to ponyfill by default?

import "@jcbhmr/html-event-error";
onerror = console.log;

Or, you could choose to ALWAYS apply the polyfill WITHOUT doing the default feature-detect if gates. This is useful when dealing with prollyfills or stuff that isn't set-in-stone and could change or is unknown. This way, if the actual onerror or whatever behaviour that's native is different, it'll still get overridden by this polyfill because the polyfill is unconditional and your code that expects this non-standard polyfill-only interface still works. It's like an explicit opt-in to a concrete pinned-version interface that won't change just because the native global object already exists or a new argument was added.

import "@jcbhmr/html-event-error/ErrorEvent-polyfill.js";
new ErrorEvent("error", { error: new Error() });

👆 This is particularly interesting given that we don't know if or when or how Node.js will implement the Worker interface. An ungated always-applied polyfill may be a good thing?

And finally in this example there's just importing something directly from the innards:

import ErrorEvent from "@jcbhmr/html-event-error/ErrorEvent.js";
new ErrorEvent("error", { error: new Error() });

Hopefully that made some sense 😅

I'm trying to push for a similar pattern in web4more/html-navigator#9

[jimmywarting]

the hole package.json conditional exports feels like very convoluted to me.
I feel more at home with top level await and doing conditional imports when needed.

kind of like

globalThis.ErrorEvent ??= await import('./error-event-polyfill.js')

I think it makes things easier for developer who create things like CDN like esm.sh, jsdeliver, unpkg jspm, bundlers etc to not have to deal with this kind package.json things.

[jcbhmr]

The reason for this: https://github.com/jcbhmr/node-45981

if (!("onerror" in globalThis)) {
  await import("#error-event-polyfill.js");
}

is that you can't reliably detect whether you're on Node.js without a lot of fuss. For this particular polyfill and some others, you don't want a if (typeof process !== "undefined") { import("node-polyfill-thing") } and you need to use the out-of-band export condition signalling to make sure you're not in Deno compat mode or Bun compat mode.

For something like this:

  "exports": {
    "deno": "./DNE",
    "bun": "./DNE",
    "node": "./index.js",
    "default": "./DNE"
  },

This is the behaviour you want in that case. I agree, bad example here since this polyfill whatwg-workers probably doesn't rely on Node.js-specific private symbols. 🤣

[jcbhmr]

As for about the "how best to apply polyfill" remark and when where or why to use import() vs export conditions: the export conditions mean that your consuming bundler doesn't need to deal with dynamic imports and can just bundle the file at compile time into you HTML JS bundle sort of like #ifdef from C macros instead of a dynamic runtime check. That's why I like to use them where they make sense.

[jimmywarting]

instead of a dynamic runtime check

You got a point there. I have done similar practices that checks OS versions once

const getIP = unix 
  ? () => exec('ifconfig')
  : () => exec('ipconfig')

Instead of doing the conditional check every time, (those making it impossible to garbage collect the unix variable and taking up more memory.

const getIP = () => exec(unix ? 'ifconfig' : 'ipconfig')

(just a simple example) but the same rule applies, better to do things at compile time rather than runtime checks.