JSON output for `exp publish:history`

Hello and thanks for Expo - it’s an amazing service!

I wonder if there is any way to get more machine-friendly output from exp publish:history and exp publish:details. JSON would be preferable.

I’m trying to automate deployments using exp pulbish:set, as described here: https://docs.expo.io/versions/latest/distribution/advanced-release-channels. For it to work I need to extract latest publication-id from the channel. The problem is that the output from exp publish:history is very eye-candy but not so much easy to process automatically. I saw that there is an --output raw general option to exp, but it seems to affect only logs.

Maybe it’s an x / y problem and I’m just approaching it wrong? How would you automate it? Basically I want to promote release from know channel (like 1.0.3) to default.

hi @lazurski, that’s a completely valid usecase :sweat_smile:

I’ve gone ahead and added the -r flag to give raw output to publish:history and publish:details. To unblock yourself now, you can grab exp from https://github.com/expo/exp and run bin/exp.js. These changes will be available via npm in the next release. Let me know if you run into problems with running exp from src.


Hey @quinlanj! Thanks for a very quick reaction.

I’ve just tested it and it’s a great improvement - almost awesome. What makes it less than awesome are log lines preceding the JSON data:

[07:49:12] Making sure project is set up correctly...
[07:49:19] Your project looks good!

I can easily to get rid of them using something like:

exp publish:history --raw | grep '{'

but still, it would be nice if exp would adhere to the Unix rule of silence. Frankly I don’t think these lines are useful at all. If the project does not look good, the command should exit with an error and appropriate message, but if it does look good, why bother to tell the user? Isn’t it expected? See Silence Is Golden for more arguments in favor of silence.

From the top of my head, these are few way it could be improved:

  • remove these messages or put them behind --verbose flag (preferred)
  • make all log lines got to stderr
  • add another (general) option, say --quiet
  • …and make --raw imply --quiet

Again, thank and have a great Monday!

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.