search

starbeamjs / starbeam

Fun and simple reactivity
Other
343 stars 16 forks source link

Tracking issue for maximum compatibility #19

Open NullVoxPopuli opened 2 years ago

NullVoxPopuli commented 2 years ago

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

1Skypack errors on modern ES Syntax. See #48 2data-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 commented 2 years ago

It's the same for skypack: https://cdn.skypack.dev/error/build:@starbeam/core@v0.5.1-0EX5krLXHP0mDxNC6Jk3 (except they give us an error)

/*
 * [Package Error] "@starbeam/core@v0.5.1" 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/core@v0.5.1\" 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/core@v0.5.1\" could not be built. ");
export default null;
NullVoxPopuli commented 2 years ago

Looks like these tools are choking on private fields. oofta

wycats commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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. :thinking: 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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

NullVoxPopuli commented 1 year ago

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