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
Rough implementation of module-relative resolution
We would like to allow modules to import from relative paths, e.g.,
import mod from './mod';
As things stand, module specifiers (the `'./mod'` bit above) are
treated as globally identifying a module, no matter where they are
used. This means:
- the same module file, imported using different specifiers, loads a
module twice;
- same specifier used from different places should refer to different
modules, but will use the same cached module.
To fix this, we need to map a specifier into something that _does_
properly identify the particular module, from wherever it's
called. The absolute filesystem path (or other plausibly canonical
path) is a good candidate; but as the code stands, there are a couple
of problems:
1. it's the ModuleResolverCallback (supplied by the client Go code) that
does the work of finding a module, so that's where the ID has to come
from.
2. the ResolverCallback (in C++ code) used by
Module::InstantiateModule to get the dependencies of a module can't
have any state associated with it.
To get around these, we have to 1. pass the canonical path back from
the ModuleResolverCallback; and 2. keep track of what each specifier
resolved to, for each module.
0 commit comments