You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: