Proof-of-concept for transform plugins

[matthewmueller]

Hey Evan,

I wanted to share a proof-of-concept for how esbuild could support simple 3rd-party plugins using the virtual filesystem. I don't expect this to be merged – this is throwaway code. If there's interest, I'd be more than happy to make this PR legit.

It's less ambitious than some of the ideas in #111, but still very flexible and the changes required are minimal. I also think it's quite fair to ask people to write their own main.go file to customize esbuild. This would be similar to how rollup.config.js or webpack.config.js works.

For a public FileSystem interface, it should be possible re-use the interface and implementation from godoc. That virtual filesystem is used quite a bit in the Go ecosystem.

package main

import "golang.org/x/tools/godoc/vfs/mapfs"

func main() {
  fs := mapfs.New(map[string]string{...})
}

[evanw]

I'm glad you're excited about esbuild plugins! I am too. This is very timely because I'm planning to start experimenting with a plugin API for esbuild soon.

I also think it's quite fair to ask people to write their own main.go file to customize esbuild. This would be similar to how rollup.config.js or webpack.config.js works.

This is a reasonable first approach, but I personally think that's too much friction. I have kept the Go and JavaScript APIs similar in shape and feature set so far and I plan to continue to do this with the plugin API. It should be possible to extend esbuild easily from JavaScript as well as Go. The JavaScript bridge will be written using IPC just like the existing JavaScript API.

And having a plugin written in JavaScript will likely lead to higher performance for certain use cases. For example, it will avoid having to repeatedly pay node's startup cost for every transform like in this example.

[matthewmueller]

Excellent! I'm thrilled to hear that this is top of mind.

This is a reasonable first approach, but I personally think that's too much friction

I absolutely agree that the IPC approach would be more accessible to more folks. I wrote something similar for doing a Go CLI where you can install third-party subcommands. If nothing else, it could be a useful point of reference: https://github.com/matthewmueller/plugin

And having a plugin written in JavaScript will likely lead to higher performance for certain use cases. For example, it will avoid having to repeatedly pay node's startup cost for every transform like in this example.

Yep. For what it's worth, this can be avoided by initializing the node service.

In (untested) code:

package transform

func Load() (*Transformer, error) {
   cmd := exec.Command("node", "service.js")
   var stdin bytes.Buffer
   cmd.Stdin = &stdin
   var stdout bytes.Buffer
   cmd.Stdout = &stdout
   err := cmd.Start()
   if err != nil {
     return nil, err
   }
   return &Transform{
      cmd: cmd,
      stdin: stdin,
      stdout: stdout,
   }, nil
}

var _ fs.FS = (*Transformer)(nil)

type Transformer struct {
   cmd *exec.Command
   stdin bytes.Buffer
   stdout bytes.Buffer
}

func (t *Transformer) ReadFile(path string) (string, bool) {
  buf, _ = ioutil.ReadFile(path)
  js, _ := svelte.Compile(buf)
  t.stdin.Write(js)
  return t.stdout.Read(), true
}

---

Excited to see this come together!