Module plugins/resolvers

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.

below is a summary what the path resolution procedure of this plugin entails, given a certain esbuild input args:

1. first, if args.pluginData.runtimePackage exists, then the plugin tries to resolve the input args.path through the use of the WorkspacePackage.resolveImport method.
   • 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.
   • if it fails, then it tries to resolve the input args.path against any potential workspace package directories (specified in the deno.json config), through the use of the WorkspacePackage.resolveWorkspaceImport method.
   • otherwise, if workspace resolution fails, then the next path resolution takes place (import-map).
2. next, if either args.pluginData.importMap exists, or config.importMap.globalImportMap exists, then the plugin will try to resolve the input args.path with respect to these import-maps, through the use of the resolvePathFromImportMap function.
   • 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).
3. 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).

4. 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.