Golang dll (for others platforms)

[Diaskhan]

I guesse we need some kind dll release for another platforms!

1. Its possible to load esbuild as dll binary file ? Seems to be yes?

2. In esbuild have some function that reads a buffer and resulting a result buffer ?

3. In esbuild could be possible to make batch file and esbuild will build minified file ?

4. Is could possible some profit if call dll in nodejs without using cli executable ?

If theese things are possible we could make a mature binary dll ! And all platforms that could use dll files could gain a profit! Because we dont need use cli executable.
C++, c# could load dll files !
Ewan what do u think about that ?

[Diaskhan]

The main problem of typescript that the parsing code not made it on top of binary executable !
The main problem of bundling, that bundling must be binary code not js!
It,s possible to make some kind bundler like parcel or webpack ? Or its very ambigious idea ?

I have some thoughts about creating some kind tooling when we could drop webpack to trash! js ecosystem created a chaos inside her self, because deno was created after all ! But deno not solved the js main problem. Binary executable tooling could solve it. And standartization.

[evanw]

I've heard loading Go code as a DLL has a lot of drawbacks. Go has its own runtime that works very differently than traditional C-style code. The runtime includes the garbage collector and the goroutine scheduler. I'm not planning to support directly loading esbuild's Go code as a DLL in another host language.

The current way of invoking esbuild from another host language is to run esbuild as a child process and speak to it over stdin and stdout. It's a form of IPC and using stdin/stdout means it's completely portable and cross-platform. This is how the node API works, and is currently implemented here.

It should be possible to port this to C and then compile that to a DLL. Keep in mind that it wouldn't be completely self-contained because you'd need to ship both the DLL and the esbuild executable as two separate files. For optimal speed, you'd want to allow multiple requests to be processed in parallel. But that would require your C API to be asynchronous and the details of that depend on what host language you're trying to integrate with.

The interchange format isn't documented because it's an internal implementation detail, but it's essentially a binary request/response format that takes an array of strings and returns a map of strings to bytes. The request consists of the operation, a request identifier, and command-line flags and the response contains the request identifier and relevant output buffers.

Since it sounds like you're interested in C# bindings, it's worth mentioning that it'd be a lot simpler to skip creating a DLL in the first place and just use C# to run esbuild as a child process. You could use the same stdin/stdout IPC format directly from C# code and even have a nice C# API with async methods. This is something you can experiment with on your own without needing to modify esbuild's code at all.

[Diaskhan]

Ok. I understand.

[yordis]

Hey @evanw what are your thoughts about using sockets as https://github.com/pulumi/pulumi project does instead of pipes?

Also, maybe figure out some of the toolkits from their repo for generating SDKs https://github.com/pulumi/pulumi/tree/master/sdk if that is possible.

[evanw]

Hey @evanw what are your thoughts about using sockets as https://github.com/pulumi/pulumi project does instead of pipes? It could potentially open the doors to communicate with esbuild directly from the browser with fewer code changes, no? (excuse my ignorance)

I don't have a need to communicate with a native-compiled esbuild directly from the browser at the moment. Currently the only scenario that esbuild's browser API is designed to operate in is one where both esbuild and the browser API are running in the browser (esbuild via WebAssembly). In that case sockets don't apply because you can't listen for connections from a browser tab.

While sockets could potentially be used to implement esbuild's non-browser APIs instead of stdin/stdout, it comes with many disadvantages. Sockets can be blocked by firewalls. They could also cause antivirus programs to incorrectly flag esbuild as a virus. Using sockets with a stable port number also runs into problems when multiple users on the same machine try to use that port at the same time.

I believe using stdin/stdout is the most appropriate way to do this.