Solvedesbuild Vue.js support

Hey @evanw,

thank you for your package! ❤️

Is the Vue.js support still not planed #27? (in case of the react support)

@yyx990803 I just added an API similar to what you proposed:

(async () => {
  const jsx = `
    import * as React from 'react'
    import * as ReactDOM from 'react-dom'

    ReactDOM.render(
      <h1>Hello, world!</h1>,
      document.getElementById('root')
    );
  `

  // Start the esbuild child process once
  const esbuild = require('esbuild')
  const service = await esbuild.startService()

  // This can be called many times without the overhead of starting a service
  const { js } = await service.transform(jsx, { loader: 'jsx' })
  console.log(js)

  // The child process can be explicitly killed when it's no longer needed
  service.stop()
})()

It should now be possible to make use of esbuild's single-file transform ability from JavaScript as a library without the overhead of process creation. The complete API is documented in the TypeScript type definitions.

Vue SFC/Template to JavaScript compilation is a completely different process from TS/ES syntax conversions or minifications. Vue's template syntax and SFC formats are framework proprietary and subject to version changes - unlike ES syntax which is a standard and a much slower moving target (TS changes happen mostly at the type checker level and syntax is also relatively stable).

More importantly, the way Vue templates are compiled need coordination with Vue's runtime to ensure correct runtime behavior, so it really doesn't make sense for esbuild to cover that.

What I do think esbuild can benefit Vue, and other JS projects in general, is exposing a way to consume esbuild from JavaScript without the overhead of starting a child process and reading/writing to disk for every file transform. An API that starts a long-living child process that can receive/send data from the Node.js main process. This allows other bundlers or dev systems (e.g. vite) to leverage esbuild as the underlying sub bundler / TS/JSX transformer / minifier much more efficiently.

The reason for this is because while esbuild is amazing, it's a black box that cannot interop with the JS ecosystem, and the bundling process doesn't allow pluggable transforms which is indispensable for building actual applications. My ideal system would be using Rollup as the bundler but esbuild for actual TS transforms and final minification.

@evanw fantastic! Thank you so much for the fast implementation.

I'm intending for esbuild to be a batch process of sorts. That's why it allows you to pass more than one file on the command line, so that many files can all be processed in one go. Is this not something that works for other bundlers or dev systems such as vite?

vite is a dev server, and it compiles source files on-demand when the browser sends in HTTP request for native ES module imports. So by nature it compiles every file in isolation without the possibility for batching.

I've been thinking a lot about a streaming protocol over stdin/stdout that would let you feed esbuild commands, and then esbuild would send the results back to you without touching disk. Would that be sufficient for this?

The limitation of that is you have to feed the esbuild process everything in one go - and as mentioned above, vite's model is by nature at odds with that. Even in the context of a bundler like Rollup, the transform for each source file is also isolated (every transform call can be async). So I imagine it would still incur the cost of a new child process on every transform.

This is the API I imagine would be useful:

const { startCompilerProcess } = require('esbuild')

;(async () => {
  const compiler = await startCompilerProcess()
  
  // under the hood, sends the buffer to esbuild for processing and sends back processed buffer
  // this can be called as many times as necessary without starting new child processes
  const compiled = await compiler.compile(srcBuffer, options).toString()

  compiler.dispose() // explicitly stop the child process (or auto exit on main process exit)
})()

I'm not very familiar with Go, but I imagine it should be a thin extra layer that doesn't affect how esbuild core works.