Open mayerraphael opened 1 year ago
I agree with your assessment. I was able to wrap the default loaders like text
and dataurl
to lock files to a new namespace and ordering the plugin before esbuild_deno_loader's plugins like:
const dataURILoader: esbuild.Plugin = {
name: 'DataURILoader',
setup(build) {
build.onResolve({ filter: /\.svg$/ }, (args) => ({
path: path.join(args.resolveDir, args.path),
namespace: textLoader.name,
}))
build.onLoad(
{ filter: /\.svg$/, namespace: textLoader.name },
async (args) => ({
contents: await Deno.readTextFile(args.path),
loader: 'dataurl',
}),
)
},
}
const opts: esbuild.BuildOptions = {
...
plugins: [
dataURILoader,
...denoPlugins() as unknown as esbuild.Plugin[],
],
...
}
It's very clumsy but fortunately isolated to my build script.
The bigger issue to me is https://github.com/denoland/deno/issues/15132 which has nothing to do with esbuild.
Because of the automatically registered "file" specifier, this conflicts with any defined loaders that also use file.
For example following esbuild options:
If i now import a graphql file like this:
The deno-loader plugin throws the following error:
The plugin should not handle all file namespaces as TypeScript/JavaScript files.