[Feature] stdin/stdout

[jpmaga]

Hey there.

It seems it is impossible as of now to use something like this:

cat file.jsx | esbuild --bundle '--define:process.env.NODE_ENV="production"' --minify | some_other_tool > bundle.js

My suggestion would be to check if there is an input file, if not use stdin. Likewise, if there is no outfile use stdout. Seems like a rather trivial change, I think. Not an expert in go or anything like that.

Personally, I use quite a lot of makefiles and shell scripts and this would allow me to manipulate what is passed to esbuild without changing source files. It also makes it considerably more easy to expand with other utils. For instance, there was issue #28 to remove console.log from production builds, this would allow it, with cat and sed before esbuild.

[zmitry]

but with this approach you can handle only single entry point, how would you handle multiple entries?

[jpmaga]

but with this approach you can handle only single entry point, how would you handle multiple entries?

If you are using multiple entry points, then there is no nice way to use this approach. In this case you'd be better off using the current way to do it.
esbuild file1.tsx file2.tsx --bundle '--define:process.env.NODE_ENV="production"' --minify --outdir=dist

This suggestion is not meant as a replacement, but rather a new feature. That is, if you don't specify file1.tsx and/or file2.tsx, esbuild tries to read stdin.

[evanw]

This request makes sense to me. Note that there would also have to be a way to specify the loader for stdin, since esbuild supports multiple loaders and the correct loader is currently determined using the file extension (js/jsx/ts/tsx).

[jpmaga]

This request makes sense to me. Note that there would also have to be a way to specify the loader for stdin, since esbuild supports multiple loaders and the correct loader is currently determined using the file extension (js/jsx/ts/tsx).

Wouldn't the --loader flag work in this case?

[evanw]

Wouldn't the --loader flag work in this case?

The --loader flag lets you configure which loader applies to a given file extension, but stdin has no file extension.

[jpmaga]

Wouldn't the --loader flag work in this case?

The --loader flag lets you configure which loader applies to a given file extension, but stdin has no file extension.

I confess i haven't looked at the implementation of the loader, but I meant extend it with something like: --loader:stdin=jsx. Ideally it would be better to have something like --loader=jsx, but that might result in a more convoluted solution.

[kzc]

In addition to stdin and stdout support it'd useful if esbuild were to support a way to disable verbose output and warnings as most UNIX command line utilities do.

$ echo 'let a=1, b=2; if (a>b) fail(); else console.log(a+b);' | rollup 

- → stdout...
let a=1, b=2; console.log(a+b);
created stdout in 52ms

$ echo 'let a=1, b=2; if (a>b) fail(); else console.log(a+b);' | rollup --silent
let a=1, b=2; console.log(a+b);

$ echo 'let a=1, b=2; if (a>b) fail(); else console.log(a+b);' | rollup --silent | terser --module -mc
console.log(3);

The absence of an input file would mean implicit stdin, and the absence of specifying output would mean stdout.

[evanw]

In addition to stdin and stdout support it'd useful if esbuild were to support a way to disable verbose output and warnings as most UNIX command line utilities do.

I can add a --silent option to esbuild. That said, I've deliberately had esbuild send that information to stderr instead of stdout so that stdout is free to do this type of stuff. So it should be possible to both direct stdout to a file and get diagnostic information over stderr.

[kzc]

Sure, by convention UNIX utilities and rollup send logging and warnings to stderr and output is sent to stdout, but there is usually a way to disable diagnostic info and warnings to reduce noise when these utilities are used within other scripts. Errors would continue to be enabled in even in the presence of --silent or equivalent.

[FredKSchott]

Just wanted to add that this feature would be huge for Snowpack. 2 use cases that this would solve for us:

1. Our Build Scripts concept is based heavily around piping from stdin & stdout (ex: src/index.js | XXXXXX | dist/index.js). With this feature a user could use esbuild as their build tool of choice.
2. Our ESM import scanner doesn't work with JSX/TSX files, so we end up having to run those files through Babel just to remove JSX syntax. We get the Babel result into memory to pass to our scanner (not written to file system).

[evanw]

Thanks for everyone's input. It's very helpful. I think I now have a good idea for what the requirements are.

[evanw]

This was a little tricky to implement given certain assumptions on file-based I/O in various places. I think I got them all but please let me know if you hit any issues.

I released this as a minor version instead of a patch version because the new stdout behavior is potentially a breaking change if something was relying on the old implicit file output behavior. The version with the new behavior is 0.3.0.

[FredKSchott]

🚀🚀🚀 Awesome! Thanks Evan, will try it today