deno-esbuild-plugin

When using a more recent minor version of ESBuild than is specified in results in a that contains two versions of . For example… If you then add an import from and into and run , you'll see that has two versions of . Despite the fact that depends on , dependencies in are written with because is treated differently. This means that using with this plugin installs two versions of ESBuild. ESBuild does not plan to move to version 1 as far as I know (it's been discussed quite a bit). So for the time being, I've included this plugin in my source tree to prevent doubling up . I'm not sure what a good solution is here other than to maybe rely on without a version to work around it. 🤷 Regardless, I thought I should raise the issue. Thanks for taking a look!

I tried to include fonts from in my bundle. Initially, esbuild complains about missing loader, so I specified loader for and . This seemingly fixed the issue, but now the font files are corrupted. Digging deeper, it appears like the bytes loaded in this line differ from the bytes on disk, i.e. using vs. . It is possible to circumvent the behavior with an additional plugin and maybe that's the intended solution. I'm not an esbuild expert and thought the option would be equivalent. It certainly seems counter-intuitive that included binary files silently get transformed. Reproduction Running the script below without args yields this in the browser: Using injects an additional plugin and yields this instead:

Resolves https://github.com/denoland/deno-esbuild-plugin/issues/31 For this PR, I took the current denoPlugin setup functions body, and split it into 3 distinct functions. Then in the new denoPlugins function, I made it create separate resolver and loader plugins that share the same workspace. The one existing test case related to plugins was broken, the one titled "plugins can participate in resolution". I re-wrote the test case to ensure both the onResolve and onLoad callbacks get called. The fake plugin being used before never had it's onResolve callback called because the mapped import was being caught and handled by the denoPlugin's onResolve since mapped exists in the import map. Then the onLoad callback wouldn't be called since the namespace would only get set if the fake plugins onResolve callback was called. Now I am having it import "simple" which is not in the import map. I have the onLoad callback transforming the code in a way that can easily be verified, it is multiplying the exported numbers by 2.