Evan Wallace

> I think converting the plugin function to string would work the same way and should avoid the need for esbuild to resolve files on its own That would break...

Here's an update. Sorry about the long post. I'm testing plugin parallelism by running each file in my JavaScript benchmark through a plugin that runs the TypeScript compiler's `transpileModule` function....

> what if you tried using one of the slower, embeddable JavaScript interpretors (without a JIT) instead of V8 for plugins? I have some experience with this. While I haven't...

> Does the plugins have to be based on JavaScript? They don't have to, no. The plugin API is available in both JavaScript and Go. My intuition is that the...

> that seems odd, is the case here of spawning a process vs a thread and then terminating them and re-spawning later? (https://stackoverflow.com/a/60488780/973988). In all scenarios, each plugin VM is...

I just released the initial version of the plugin API. It's somewhat different than the version on the `plugins` branch: * Plugins are now objects with a name property and...

> So I think it would be better if the "Go plugins" can also be used with a simple `npm install` command and one additional line in the configuration. Yes,...

FYI Plugin documentation is up now: https://esbuild.github.io/plugins/ > @evanw Would it make sense to expose the esbuild configuration options to the plugins? I would like to be able to read...

> Is there a recommended way to distribute Go plugins? I can't think of anything clever. It seems like I need to re-compile esbuild with my plugin. That's correct. The...

FYI: I just created a repo for issue #632 to serve as a centralized list of 3rd-party esbuild plugins: https://github.com/esbuild/community-plugins I didn't want to pre-populate the list with existing esbuild...