Custom file extensions/hooking into default snowpack plugins

[jdb8]

Apologies if this has been asked elsewhere, I had trouble knowing what exactly to search for.

I'll start by describing an example usecase which I'm having trouble working out how to support cleanly. Let's say I, for some reason, have come up with a custom file extension which I want to transpile down to js via esbuild (let's say .jdb8 as an example). Ideally, I don't want to have to define my own set of plugins if I essentially want to treat this file extension as equivalent to .jsx - that is, I want to transpile jsx syntax contained within, with no extra custom stuff.

It seems like I could just use @snowpack/plugin-babel and define .jdb8 in my input array, but it feels wasteful if I'm already happy with how the builtin esbuild plugin would otherwise be handling things. What I really want, ideally, is to somehow tell snowpack to treat any .jdb8 files as if they were .jsx, with the same transpilation/file renaming that would take place if referencing a .jsx file on disk.

I tried making a simple no-op load plugin to achieve this, thinking that if my load plugin set its resolve object to input: ['.jdb8'], output: ['.jsx'] that snowpack might "pick up" the interim-output of .jsx and continue on. But I think that didn't work because of the restriction that load plugins only run once when the file is first processed from disk, and further plugins including the inbuilt esbuild one cannot continue to transpile that .jsx file down to a plain .js one.

My understanding is that config.alias does not support regex or globs, so that also rules this out as a way to "alias" .jdb8 to .jsx.

Sorry if this example is a bit contrived: the point really is that there are cases where file extensions don't necessarily match up 100% to snowpack's internal expectations (a better real world example of this is css modules relying on .module.css), so if there was some kind of escape hatch available it would make it a lot easier to migrate a legacy codebase without doing a ton of file renames.