Plugin : Regex on contents of file?
Brian-McBride opened this issue · comments
I like the fact that you are doing regex on the Go side of things.
I have a loader plugin that I only want to trigger on certain contents of files. Right now, I am forced to load up every ts file, look through it, then if my regex matches, I return modified output.
I am sure doing a regex on the file on the Go side of things would be much faster, triggering an onLoad event if the regex tests positive for the file contents.
The reason why this doesn't work this way is that onLoad plugins determine where the file contents come from, and are run before esbuild attempts to read the file. This is required for plugins that load files from places other than the file system (e.g. from node's memory, from the internet, within a zip file for Yarn 2 PnP). Doing this could require esbuild to attempt to read the file before plugins are run, which could potentially be slower if the plugin also loads the file.
Maybe there is room for an after-load hook?
This is the very simple plugin I have going. But it is a shame to read every .ts file just to see if it has a decorator. A hook right after reading a file, but before processing it. I don't want to slow down esbuild. So something for sure that won't bother to even check if no plugin is registered.
an afterLoad or onTranspile
Just to be more specific, this is the regex:
/((?<![(\s]\s*['"])@\w[.[\]\w\d]*\s*(?![;])[((?=\s)])/This is doing a good job at finding decorator statements. If a decorator is found, it goes through Typescript's transpileModule and returns that output to contents
It works right now. And honestly, it still feels super fast. But I can't help thinking that I'm slowing the whole thing down by having to pre-check every file before esbuild can do its magic on that file.
Sorry but I consider this out of scope. It's fast enough to not be worth the complexity of something like this in my opinion. Closing.