input => Input

The main use-case is one input argument, so would really like to optimize for that, but still support the edge-case of multiple arguments.

This isn't how stdin is intended. At least, this is completely counterintuitive for any other program out there. Usually how it works is program file.txt or cat file.txt | program.

This assumes the command line input is instead input as well. This will confuse a ton of people if Meow's code handling assumes this.

Is there a big difference in echo "foo bar" | cli and cat file.txt | cli where the content of file.txt is foo bar? I assumed, if I test echo "foo bar" | cli, then cat file.txt | cli will work as well?

That's not what I mean. Usually programs that accept filenames as arguments are the ones that employ the use of stdin.

For instance:

cat > some-file.txt <<EOF
some text
EOF

grep "text" some-file.txt
echo "some text" | grep "text"

sed 's/some/thing/' some-file.txt
echo "some text" | sed 's/some/thing/'

Instead, this PR seems to support the usage of:

cat > some-prog.js <<EOF
// ...
console.log(meow.input);
// ...
EOF

some-prog.js This Is Some Text
# doing the same as
echo This Is Some Text | some-prog.js

Which is going to confuse a lot of people.

Usually programs that accept filenames as arguments are the ones that employ the use of stdin.

Sure, but I also often use it for CLI's that accept text input too, to make it easier for everyone to use it.

Then they could use either of these:

$ cli-app foo
$ echo foo | cli-app

Actually, I take back my last comment. Better to use stdin for just string input. No point in doing both, and stdin should be preferred as it works nicely in a pipe chain.

Isn't it against the rules or am I missing something?

get-stdin does not support 0.10 and thus does not come bundled with pinkie-promise. So either we drop 0.10 in meow, or add pinkie-promise to get-stdin in order to get rid of this.