Conflicts with other loaders

[mayerraphael]

Because of the automatically registered "file" specifier, this conflicts with any defined loaders that also use file.

For example following esbuild options:

{
    plugins: [...denoPlugins()],
    entryPoints: entryPoints,
    ...
    loader: {
      ".graphql": "file",
    },
  }

If i now import a graphql file like this:

import query from "./query.graphql";

The deno-loader plugin throws the following error:

 The module's source code could not be parsed: Expected ',', got ':'
 ~ [plugin deno-loader]

The plugin should not handle all file namespaces as TypeScript/JavaScript files.

[niedzielski]

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 denoland/deno#15132 which has nothing to do with esbuild.