-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vue.js support #75
Comments
If you use Vue with JSX you could probably use custom |
Sadly i do not use Vue with JSX :/ |
Evan mentioned in #27:
Even though I use svelte and want to use esbuild, it makes sense to me that Evan wants to create a bundler focused on a smaller scope - it's exactly what I would be doing too. I've been thinking a lot about bundlers lately and we really do need a fresh take like this. Rewriting the vue or svelte compiler really just doesn't belong in this project. Though, if esbuild has plugin support one day (or at least file pipelining hooks), I can see someone being able to call the vue cli or a svelte cli compiler on each file before esbuild starts the bundling process. And it's possible there's members of the community that will try to recreate the vue/svelte compilers in golang, rust, whatever to improve performance even further :) I created svelvet and once esbuild supports generating esm bundle outputs (#48) I might even pivot svelvet to use esbuild instead of snowpack. |
Couldn't it be used as a library by a Vue/Svelte compiler? |
Exactly! That's my point here:
Though, file pipelining hooks in esbuild could be a really cool way to do plugin support without requiring plugins to be written in a certain language. Just calling other cli tools at certain steps in the bundling process would allow precompilation of js and other assets possibly, before esbuild finishes the bundle. |
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 The reason for this is because while |
Well said!
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?
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? |
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.
The limitation of that is you have to feed the 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 |
Can |
@CyberAP I think the current binary just terminates itself when the processing is complete. |
This, to me, sounds like having an RPC server on the esbuild side and having js clients open a persistent connection to it. To do that, esbuild should first implement an API-based approach which I guess is not how it is designed right now. |
@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. |
@evanw fantastic! Thank you so much for the fast implementation. |
Was this API sufficient to address this issue on the esbuild side? I assume there's still more work to fully integrate this API into the Vue ecosystem, but I don't think this issue is the appropriate place to track that work. |
Yes, already integrated in vite. I think this can be closed - Thanks again!
…On Thu, May 7, 2020 at 6:46 AM Evan Wallace ***@***.***> wrote:
Was this API sufficient to address this issue on the esbuild side? I
assume there's still more work to fully integrate this API into the Vue
ecosystem, but I don't think this issue is the appropriate place to track
that work.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#75 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADZ6XWD6HMJRDIOHFZQXQDRQKGPDANCNFSM4MNGFIUA>
.
|
Hey @evanw,
thank you for your package! ❤️
Is the Vue.js support still not planed #27? (in case of the react support)
The text was updated successfully, but these errors were encountered: