Unusable with other plugins and non ts/js default loaders

[KyleJune]

I made an esbuild plugin for PostCSS. When I try to have esbuild bundle my css files, it appears that the deno loader plugin tries handling the data url imports from within css files. esbuild has a built in loader for data-urls and many other imports. See here for more information about that.

Anyway, when I use @luca/esbuild-deno-loader with @udibo/esbuild-plugin-postcss, I end up having issues if my css file has background-image urls in it.

I believe this is the cause of the problem. The onResolve filter means it will catch any import path, including for types it is not designed to handle.

esbuild_deno_loader/src/plugin_deno_resolver.ts

Line 83 in 2bc9a9d

build.onResolve({ filter: /.*/ }, async function onResolve(args) {

This could be fixed by changing the filter to limit the types of imports it would try to handle. Alternatively, instead of changing the filter, you could add more conditions for when it would return undefined. Returning undefined would also allow it to get caught by later plugins or by the default esbuild loaders mentioned earlier.

Fixing this would enable people to use other esbuild plugins with the esbuild deno loader plugin. Unless this issue is fixed, users would have to spin up 2 separate build processes to build their application, one for bundling their TS/JS code, and another for bundling their styles.

---

Reproduction path:

In this example, I just have a single css file entrypoint. But in my actual application, I have my ts entrypoint along with my css entrypoints. My postcss plugin should be handling all the css entrypoints then the denoPlugins should only be handling the TS/JS entrypoints.

build.ts:

import * as esbuild from "npm:esbuild@0.24.0";
import { denoPlugins } from "jsr:@luca/esbuild-deno-loader@^0.11.1";
import { postCSSPlugin } from "jsr:@udibo/esbuild-plugin-postcss@0.1";

const result = await esbuild.build({
  plugins: [postCSSPlugin(), ...denoPlugins()],
  entryPoints: ["./example.css"],
  outdir: "./dist",
  bundle: true,
  format: "esm",
});

console.log(result.outputFiles);

esbuild.stop();

example.css:

.myComponent {
  background-image: url("data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Ccircle%20r%3D'10'%20cx%3D'10'%20cy%3D'10'%20fill%3D'red'%20%2F%3E%3C%2Fsvg%3E");
}

You could also remove my postCSSPlugin() and encounter a similar issue, where it isn't using the default css loader that comes with esbuild since esbuild-deno-loader is trying to process the css file first.

Here is what happens when you try doing that.

Then if I remove the denoPlugins, esbuild is able to build my css file with no issue. It successfully copies the file to the dist directory when not using the denoPlugins.

[omar-azmi]

Hi @KyleJune , I wrote an esbuild plugin (https://github.com/oazmi/esbuild-plugin-deno) that resolves http links and jsr packages, without depending on Deno-runtime's module resolution/caching.
Moreover, it avoids trapping resolved paths into a single namespace, allowing other plugins (including esbuild's native resolve/loader) to take over whenever they can.

If you're interested in trying it out with your postCSS plugin, please check out: jsr:@oazmi/esbuild-plugin-deno.

I know you submitted a PR to fix this issue (and I was kind of hoping that it would get merged soon enough), but the fundamental problem in my opinion is that this plugin "traps" everything into its own namespaces. So, integrating it with most plugins would require you to write a long list of regex filters which the deno plugin should ignore. This is kind of tedious and not good in practice.
Which is why I thought it would be better to write a new plugin that avoids this issue in the first place.

By the way, the minimal example that you provided in your issue works fine with my plugin, even if my plugin comes first (i.e. it is non-intrusive to other plugins):

inputs:

file: ./build.ts

import { denoPlugins } from "jsr:@oazmi/esbuild-plugin-deno@0.1.0"
import { postCSSPlugin } from "jsr:@udibo/esbuild-plugin-postcss@0.1.3"
import * as esbuild from "npm:esbuild@0.24.2"


Deno.test("test issue \"https://github.com/lucacasonato/esbuild_deno_loader/issues/159\"", async () => {
	const result = await esbuild.build({
		absWorkingDir: import.meta.dirname,
		plugins: [...denoPlugins(), postCSSPlugin()],
		entryPoints: ["./example.module.css"],
		outdir: "./dist/",
		bundle: true,
		format: "esm",
		write: false,
	})

	console.log(result.outputFiles.map((file) => ({ path: file.path, text: file.text })))
	await esbuild.stop()
	await new Promise((resolve) => { setTimeout(resolve, 500) })
})

file: ./example.module.css

.myComponent {
	background-image: url("data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Ccircle%20r%3D'10'%20cx%3D'10'%20cy%3D'10'%20fill%3D'red'%20%2F%3E%3C%2Fsvg%3E");
}

outputs:

file ./dist/example.module.css

/* postcss-module:./example.module.css */
._myComponent_11tg2_1 {
  background-image: url("data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Ccircle%20r%3D'10'%20cx%3D'10'%20cy%3D'10'%20fill%3D'red'%20%2F%3E%3C%2Fsvg%3E");
}

file: ./example.module.css.json

{"myComponent":"_myComponent_11tg2_1"}

(I am curious if the json file is supposed to end up in the current-working-directory, rather than the outdir. could it be a bug?)

If you've got other complex test cases I'd be happy to test them out, since that might expose potential bugs in my code.