Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Runtime detection of JS shim output mode #3157

Open
daxpedda opened this issue Nov 19, 2022 · 1 comment
Open

Runtime detection of JS shim output mode #3157

daxpedda opened this issue Nov 19, 2022 · 1 comment

Comments

@daxpedda
Copy link
Collaborator

Motivation

When re-using the JS shim for workers and worklets it's necessary to know if the shim is an ES module or a regular JS script to import it correctly. I found that common solutions just assumed that it is a ES module because everybody uses Chrome (Firefox doesn't support ES modules in workers and worklets yet).

Currently there is no way to know during runtime which it is, a re-usable library hard.

Proposed Solution

A simple static function that returns if it's a ES module or not.

Alternatives

The alternative is to continue solving this issue during build time, totally doable, just increases user friction.

Additional Context

This is similar to #3032, it's a tacked on solution to a bigger problem that won't be solved that way. This could be solved by a more expansive strategy like #3034.

I would like to figure out if we can continue to figure out more temporary solutions in the meantime, as it seems that maintainers don't have the review capacity for bigger features.

Happy to make the PR myself.

@Liamolucko
Copy link
Collaborator

The longer-term solution I was thinking of for this was to allow specifying in link_to! which target the resulting JS shims are. That way, when creating a worker script, the no-modules target could always be used, irrespective of which target the main code is. It would result in double the JS shims, though, since separate ones would have to be made for the main app and the worker (unless they happen to be the same target).

I don't think it would hurt to allow checking the current target, though, so I'm happy to merge that as an interim solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants