Tracking issue for maximum compatibility

[NullVoxPopuli]

❌ = confirmed not working
✔️ = confirmed working
⏳ = pending further investigation

• = investigation not complete
• = investigation complete

• CDNs
  • ESM CDN compatibility #48
  • esm.sh: https://jsbin.com/kivuqal/1/edit?html,output
  • esm.run: doesn't support private fields (too much compilation)
• REPLs + CDN or built-in packager
  • jsfiddle
  • jsrun
  • repilit
    • CJS - native require²
  • codepen
    • ❌ ESM¹
  • ✔️ Stackblitz (turbo)
• Analysis tools
  • ✔️ bundlejs.com
  • ✔️ bundlephobia.com
• Packgers
  • Vite
    • ✔️ ESM
  • Webpack

¹Skypack errors on modern ES Syntax. See #48
²data-uri-to-buffer (a dependency of @starbeam/debug) is ESM only, and it seems Starbeam can't be used in a CJS environment (unless data-uri-to-buffer is transpiled to CJS)

---

---

Please comment here if the build doesn't work out of the box in some environment. That includes bundlers and CDNs.

Original Report

✂️ issues reported on #48 ✂️

I believe supporting this would be good, as we want "just trying it" to be as easy as possible.

At first glance tho, I don't know why this error occurred -- they don't give enough information and we build with rollup -- so I'm going to open an issue on their repo as well.

[NullVoxPopuli]

It's the same for skypack: https://cdn.skypack.dev/error/build:@starbeam/[email protected]
(except they give us an error)

/*
 * [Package Error] "@starbeam/[email protected]" could not be built. 
 *
 *   [1/5] Verifying package is valid…
 *   [2/5] Installing dependencies from npm…
 *   [3/5] Building package using esinstall…
 *   Running esinstall...
 *   Failed to load node_modules/@starbeam/core/dist/index.js
 *     Unexpected token (67:10) in @starbeam/core/dist/index.js
 *   Install failed.
 *   Install failed.
 *
 * How to fix:
 *   - If you believe this to be an error in Skypack, file an issue here: https://github.com/skypackjs/skypack-cdn/issues
 *   - If you believe this to be an issue in the package, share this URL with the package authors to help them debug & fix.
 *   - Use https://skypack.dev/ to find a web-friendly alternative to find another package.
 */

console.warn("[Package Error] \"@starbeam/[email protected]\" could not be built. \n[1/5] Verifying package is valid…\n[2/5] Installing dependencies from npm…\n[3/5] Building package using esinstall…\nRunning esinstall...\nFailed to load node_modules/@starbeam/core/dist/index.js\n  Unexpected token (67:10) in @starbeam/core/dist/index.js\nInstall failed.\nInstall failed.");
throw new Error("[Package Error] \"@starbeam/[email protected]\" could not be built. ");
export default null;

[NullVoxPopuli]

Looks like these tools are choking on private fields. oofta

[wycats]

I think this suggests that we should make a dedicated build for this sort of use.

One question: is there an exports-map entry that these tools will prefer? Is it just a matter of making the default export a lowest-common-denominator build?

[NullVoxPopuli]

I think this suggests that we should make a dedicated build for this sort of use.

how do you mean? the jsdeliver folks said they were working on updating their terser config so that private properties were supported -- that would allow us to use things as they are (or until we uncover a new problem)

[wycats]

@NullVoxPopuli what about other CDNs, etc?

I think we need a "maximum compatibility" build (maybe UMD 🤮) that we make the default export in export maps as well as the main. What do you think?

[NullVoxPopuli]

is it possible to avoid duplication in non-ESM environments? irrc, the main thing for interop between "things using starbeam" is that the auto-tracking implementation can't be duplicated. 🤔 Though, maybe if we're clear about the intend and purpose of these builds, it's fine? It probably makes sense to clarify in documentation (and comment in the built file itself) that UMD/etc is intended for small demos and not for libraries or bigger things, etc?

[wycats]

I'm hopeful that using export maps will help clarify the role of each build, but a lot depends on how each part of the ecosystem interprets main, module, and the various fields in export maps in practice.

[matthewp]

Skypack is unlikely to receive new updates. It is based on Snowpack which is since deprecated, so it's not going to work with modern packages going forward. I would suggest using esm.sh or something else instead.

[NullVoxPopuli]

esm.run is a delight on what I have used it for so far. 10/10 can recommend

[NullVoxPopuli]

esm.sh over here: https://jsbin.com/kivuqal/1/edit?html,output

Also, going to remove all the CJS checkboxes, because ESM in node is really good these days