speed up performance by letting esbuild do visiting and parsing of imported files

[bobbyrenwick]

Thanks for the two previous updates @louisscruz 🙌🏻

There's one final optimisation that you can make, which could be important given that esbuild's major feature is performance. At the moment it seems like for every imported file you're also reading and parsing the file which means if you have 2 .graphql files that import sharedFragment.ts, that file will actually be read and parsed 3 times. The result of your plugin is passed directly to the js loader of esbuild, which handles the parsing and loading of imports by itself, so you can just transform the text in a single file, pass the result to esbuild and let it handle the recursion of the files for imports etc.

I could well have misunderstood the code so feel free to tell me that's not what it's doing!

[louisscruz]

@bobbyrenwick great point. One thing I failed to catch when reading over the plugin documentation initially is that it looks like imports returned from onLoad content are still resolved. At least that what it looks like from the WASM example. (Kind of had a mental model that once you use onLoad that you were ejecting into handling imports yourself – probably just because we already have to do our own import parsing, so I just continued down that rabbit hole.)

Going to give this a shot. There might be a trade-off or two in terms of expected behavior of the plugin, but if this largely works, we should definitely go for having ESBuild handle all the resolution stuff.

[zovt]

Hey! Was there ever any exploration done with this?