More control over in/out formats #357
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
squaremo
force-pushed
the
stdin-stdout-format
branch
2 times, most recently
from
e3529b4 to
f1c6402
Compare
This adds a flag `jk generate --format`, which will force the output to either YAML or JSON. If printing to stdout, this means all values are printed as whichever foramt, with streams being inlined as before. If writing to files, the file extension when present will be changed. Values with a stream (or multidoc) format -- YAMLStream, JSONStream -- will still be written as streams.
.. and refactor. You can now
jk transform --format=json -c 'x => update(x)' foo.yaml
and it will write a JSON file out (or print JSON if you use --stdout).
This makes the tests for `--format` more specific, by giving each values to be output different content that can be recognised in the expected value.
The new flag --stdin-format instructs `jk transform` to read from stdin (as well as any files that are given as arguments). The possible values are `json` meaning expect JSON values, and `yaml` meaning expect a YAML stream. An alternative would be the conventional `-` denoting stdin; however, you would still need to provide a format. Defaulting to YAML would read a JSON value equally well, but (crucially) not multiple JSON values.
Instead of taking --stdin-format to imply reading from stdin, use the
convention of supplying `-` as an argument to denote reading from
stdin, and just use the flag to alter how it's read.
This will line up better with expectations; and, since --stdin-format
can have a default (of "yaml"), invocations can be concise:
jk transform ./script.js -
.. rather than
jk transform ./script.js --stdin-format=yaml
Note that _no_ arguments does not imply reading from stdin. I did not
want something that accidentally supplies no filenames to block, since
that would make automation using `jk transform` brittle.
squaremo
force-pushed
the
stdin-stdout-format
branch
from
f1c6402 to
117f5ef
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds a flag
jk generate --format, which will force the outputto either YAML or JSON.
If printing to stdout, this means all values are printed as whichever
foramt, with streams being inlined as before.
If writing to files, the file extension when present will be
changed. Values with a stream (or multidoc) format -- YAMLStream,
JSONStream -- will still be written as streams.
Using an argument of
-now instructsjk transformto read values from stdin (as well as any files supplied as arguments).The new flag --stdin-format tells it what format to expect (it defaults to 'yaml').
The possible values are
jsonmeaning expect JSON values, andyamlmeaningexpect a YAML stream.
Reading from stdin implies
--stdoutas well, since the alternative is to make up a filename to write it to. I'm not sure of the ergonomics of that choice.