Skip to content

πŸš€ Feature Request β€” Provide the raw-specifier in the Module fallback service requests #2112

Description

@dario-piotrowicz

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:

/Users/me/project/node_modules/.pnpm/react@18.3.1/node_modules/react/cjs/react-jsx-dev-runtime.development.js

that we need to import and run.

The above works fine initially, but can easily break when the module in question includes require/import calls, such for example as:

var React = require('react');

and

var util = require('./utils.js');

The problem being that the above require calls produce respectively the following specifiers and referrers:

 specifier: /Users/me/project/node_modules/.pnpm/react@18.3.1/node_modules/react/cjs/react
 referrer: /Users/me/project/node_modules/.pnpm/react@18.3.1/node_modules/react/cjs/react-jsx-dev-runtime.development.js

and

 specifier: /Users/me/project/node_modules/.pnpm/react@18.3.1/node_modules/react/cjs/utils
 referrer: /Users/me/project/node_modules/.pnpm/react@18.3.1/node_modules/react/cjs/react-jsx-dev-runtime.development.js

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)

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions