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
It would be great if the requests that the module fallback server receive could provide the original/raw/unaltered specifier exactly as it was defined in the referrer code.
To give more context we've been experimenting with using the module fallback service alongside the Vite environment api in order to lazily import cjs modules (which we could otherwise not import since vite does not perform any transformation on such code).
Meaning that, in workerd (specifically in the ModuleEvaluator's runExternalModule method), we receive a path such as the following from Vite:
and from these we are unable to distinguish/differentiate the fact that react is referring to a dependency package and utils a local file (which for obvious reasons is fundamental for us).
So it would be necessary for us to also have the actual import specifier being used (i.e. "react" and "./utils.js" respectively)
(this would not introduce any breaking change if such specifier would be added to the request's search params or headers potentially as a raw-specifier/original-specifier or something along those lines).
Note
We could check the file extension to discern which is which but that is quite brittle as libraries can also end with .js etc...
As an example of the specifiers we have in mind, those should follow this comment: #1423 (comment)
(but again probably with a different search param name instead of specifier for backward compatibility)
It would be great if the requests that the module fallback server receive could provide the original/raw/unaltered specifier exactly as it was defined in the referrer code.
To give more context we've been experimenting with using the module fallback service alongside the Vite environment api in order to lazily import cjs modules (which we could otherwise not import since vite does not perform any transformation on such code).
Meaning that, in workerd (specifically in the
ModuleEvaluator'srunExternalModulemethod), we receive a path such as the following from Vite:that we need to import and run.
The above works fine initially, but can easily break when the module in question includes
require/importcalls, such for example as:and
The problem being that the above
requirecalls produce respectively the followingspecifiers andreferrers:and
and from these we are unable to distinguish/differentiate the fact that
reactis referring to a dependency package andutilsa local file (which for obvious reasons is fundamental for us).So it would be necessary for us to also have the actual import specifier being used (i.e.
"react"and"./utils.js"respectively)(this would not introduce any breaking change if such specifier would be added to the request's search params or headers potentially as a
raw-specifier/original-specifieror something along those lines).Note
We could check the file extension to discern which is which but that is quite brittle as libraries can also end with
.jsetc...As an example of the
specifiers we have in mind, those should follow this comment: #1423 (comment)(but again probably with a different search param name instead of
specifierfor backward compatibility)