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 loader type by inspecting its "content-type" http-header and/or its path extension/suffix.
Important
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).
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).