this submodule contains a namespaced esbuild plugin that resolves paths based on the three strategies:
runtime-package resolution, import-map resolution, and absolute-path resolution.
Note
the default namespace you should use in your plugins to call this pipeline of resolvers is PLUGIN_NAMESPACE.RESOLVER_PIPELINE.
otherwise, if you want, you can customize the namespace of this plugin by specifying it in the config.namespace option.
below is a summary what the path resolution procedure of this plugin entails, given a certain esbuild input args:
if it succeeds (i.e. args.path was an alias/import-map specified in the package file),
then the resolved path, along with the original args.pluginData, is returned.
otherwise, if it fails, then the next path resolution takes place (import-map).
if it succeeds (i.e. args.path was part of the import-map(s)),
then the resolved path, along with the original args.pluginData, is returned.
otherwise, if it fails, then the next path resolution will take place (node-modules).
up ahead, we let esbuild's native resolver give a shot at resolving args.path as a node-module package,
if and only if the path is neither a relative path (i.e. doesn't begin with "./" or "../"),
nor is it an absolute path (such as "http://example.com/...", or "C:/users/...").
this is because these scenarios can be handled much quicker by the next path-resolver that follows this one
(since that one does not perform filesystem read/scan operations, unlike esbuild's native resolver).
if it succeeds (i.e. args.path was indeed some package inside some "./node_modules/" folder up the directory tree),
then the resolved absolute filesystem path of the resource will be returned.
otherwise, if it fails, then the next path resolution will take place (path-joining).
Tip
under the hood, this function uses the nodeModulesResolverFactory function that initializes a mock build process,
which lets us indirectly query esbuild for the resolved path to the resource (if any).
finally, when all else has failed and we've made it to here, and args.path is a relative path:
then we'll simply compute the absolute path of the input args.path by combining it with args.importer, and args.resolveDir.
if neither of those two arguments are non-empty strings, then we will resort to using esbuild's absWorkingDir build option.
if absWorkingDir was itself not specified, then we will fallback to the runtime's current-working-directory as the base directory of args.path.
and again, the original args.pluginData is returned along with the result, so that the child dependnecies can inherit it.
this submodule contains a namespaced esbuild plugin that resolves paths based on the three strategies: runtime-package resolution, import-map resolution, and absolute-path resolution.
the default namespace you should use in your plugins to call this pipeline of resolvers is PLUGIN_NAMESPACE.RESOLVER_PIPELINE. otherwise, if you want, you can customize the namespace of this plugin by specifying it in the
config.namespaceoption.below is a summary what the path resolution procedure of this plugin entails, given a certain esbuild input
args:args.pluginData.runtimePackageexists, then the plugin tries to resolve the inputargs.paththrough the use of the RuntimePackage.resolveImport method.args.pathwas an alias/import-map specified in the package file), then the resolved path, along with the originalargs.pluginData, is returned.args.pluginData.importMapexists, orconfig.importMap.globalImportMapexists, then the plugin will try to resolve the inputargs.pathwith respect to these import-maps, through the use of the resolvePathFromImportMap function.args.pathwas part of the import-map(s)), then the resolved path, along with the originalargs.pluginData, is returned.args.pathas a node-module package, if and only if the path is neither a relative path (i.e. doesn't begin with"./"or"../"), nor is it an absolute path (such as "http://example.com/...", or "C:/users/..."). this is because these scenarios can be handled much quicker by the next path-resolver that follows this one (since that one does not perform filesystem read/scan operations, unlike esbuild's native resolver).args.pathwas indeed some package inside some"./node_modules/"folder up the directory tree), then the resolved absolute filesystem path of the resource will be returned.under the hood, this function uses the nodeModulesResolverFactory function that initializes a mock build process, which lets us indirectly query esbuild for the resolved path to the resource (if any).
args.pathis a relative path:args.pathby combining it withargs.importer, andargs.resolveDir.absWorkingDirbuild option.absWorkingDirwas itself not specified, then we will fallback to the runtime's current-working-directory as the base directory ofargs.path.args.pluginDatais returned along with the result, so that the child dependnecies can inherit it.