Optionalfilters?: RegExp[]the regex filters which the plugin's resolvers should use for the interception of resource-paths.
Optionalnamespace?: stringspecify the namespace that the http plugin's loader should use for fetchable resources.
if the convertFileUriToLocalPath option is enabled (default),
then file-uris will not use this namespace, and instead adopt the regular "" namespace.
it is best if you don't modify it to something besides the default value PLUGIN_NAMESPACE.LOADER_HTTP, as this plugin relies on the entry-plugin's prior intervention to have relative-paths and import-map paths resolved to a full http path.
OptionaldefaultLoader?: anythe default loader that the plugin's loader should use for unidentified content types.
if you would like to use esbuild's own default loader, set the value to "default".
OptionalacceptLoaders?: Loader[]only accept the following subset of loaders when auto content-detection is used for guessing the loader type.
if there is no intersection between the set of guessed loaders, and this set of acceptLoaders,
then the default loader (defaultLoader) will be used as a fallback.
OptionalacceptNamespaces?: (undefined | string)[]specify which namespaces should be intercepted by the http-plugin.
all other namespaces will not be processed by this plugin.
if you have a plugin with a custom loader that works under some "custom-namespace",
you can include your "custom-namespace" here, so that if it performs an http-import,
that import path will be captured by this plugin, and then consequently fetched by this plugin's http-loader.
but do note that the namespace of the loaded resource will switch to this plugin's loader namespace
(which defaults to PLUGIN_NAMESPACE.LOADER_HTTP), instead of your "custom-namespace".
[undefined, "", "file"] (also this plugin's namespace gets added later on)
OptionalconvertFileUriToLocalPath?: { enabled?: boolean; resolveAgain?: boolean }specify if "file://" uris should be converted to local paths,
so that esbuild natively loads them, instead of us fetching the resource ourselves.
when this option is enabled, the resulting resolved local-path of a file uris will not use the namespace config option,
and instead adopt the the default namespace "", so that esbuild (or some other plugin) would be capable of loading it.
for best compatibility with ./node_modules/ resolution and other plugins, it is best to have this option enabled always.
that's because if a file uri ends up becoming the resolveDir of an npm-package resource,
then esbuild will halt and complain that it does not understand the "non-absolute" local path specified,
because it is incapable of interpreting file uris, and will refuse to scan directories based on it.
pluginData.
on the otherhand, our url-loader will not do such a thingOptionalenabled?: booleanenable or disable file-uri to local path conversion.
OptionalresolveAgain?: booleanenable or disable re-resolution of the local path, to allow other plugins to intercept.
Optionallog?: boolean | LoggerFunction
this plugin intercepts
"http://","https://", and"file://"resource paths and redirects them to the PLUGIN_NAMESPACE.LOADER_HTTP namespace, where they can be fetched and loaded by a dedicated loader.the loader function tries to guess the resource's
loadertype by inspecting its"content-type"http-header and/or its path extension/suffix.you are generally expected to have the entryPlugin in your list of esbuild plugins (preferably in the beginning) for this plugin to function correctly. the resolver portion of this plugin is intentionally made to be super basic, so that all it does is redirect absolute urls to its loader's namespace. this means that the resolver in this plugin will not carry out relative-path/import-map/package-alias resolution. which is why you should have the entryPlugin loaded, in order for these various path resolutions to take place.
TODO: maybe I should also create a standalone http plugin in the future that will not rely on entryPlugin, in case someone really just wants to use a single http plugin without all the fancy entry-point plugin-data injection. although, then it would not be recommended to use that standalone version along side an entryPlugin, since it will lead to some redundant ping-pongging (but the final resolved result will remain unchanged).