jq should not sort object keys by default

[gcatlin]

echo '{"a":1, "b":2, "c":3, "d":4}' | jq '.' produces the following output:

{
  "d": 4,
  "c": 3,
  "b": 2,
  "a": 1
}

Observed behavior: keys were sorted in reverse order

Expected behavior: keys should be in the original order

[stedolan]

Hmm. Currently, jq doesn't care about the order of (distinct) fields within an object, like most other JSON implementations and the JSON spec. I suppose it could preserve the original order without too much effort (this would have something of a performance cost everywhere, but I'm not sure how big a deal it would be).

[scy]

I second that. When using jq to debug web services etc., being able to see the original order of the JSON keys can be an important feature. If, for example, you want to have your JSON-returning REST API not only to be machine-consumable, but also human-readable to some extent, you might design it in such a way that the returned JSON is not in random or alphabetical order, but instead in a semantically useful way. (For example, first the ID of a blog post, then the author, then the title, then the contents.)

In order (pun not intended) to lose as little as possible of the original JSON's structure, jq should preserve the original order.

[vito-c]

Sorry but is there a way to sort the keys? I would have rather have the keys sorted then not... makes it easier to do a diff... which leads to my other question is there way to do a diff? lol

[devoncrouse]

+1. I've had cases where I want to use JQ to add keys to each element in a large JSON config, but don't want the entire file being reordered (under source control and our ordering of keys is intuitive).

[casfr]

I also have a case where I don't want the sorting from the output. I'm working on a AWS DynamoDB table cloning script and basically I'm grabbing the source table definition thru their API and I'm parsing it thru JQ and unfortunately the original ordering "AttributeName AttributeType" goes to "AttributeType AttributeName" after running thru JQ. So when I try to create the target table with the JQ json, the AWS API is complaining about the ordering. So anyway this is not a major issue and I will reverse the ordering thru other means but having a "--no-order" parameter to JQ could be useful. Keep up the good work. JQ is very cool and handy.

[mslinn]

If I persist an object with sorted keys to a file, then read it back, the order of the keys is random. I would like an option to have the keys in a predictable order.

[nicowilliams]

When browsing JSON data with jq it's nice to have objects sorted in some
sort of easy-to-read way. I don't know what that is -- since object names
are not expected to be ordered, they generally aren't, and whatever thing
wrote the JSON text I'm browsing is very likely to be using a hash table
just like jq does, so no real order is expected.

Preserving input order is only really useful when there are JSON encoders
that so something useful w.r.t. object name ordering. I'm sure such
encoders exist, but I'm not sure that doing anything about them in jq is
worthwhile. Still, one thought is to have alternate object implementations
in libjv and to pick one in the jv_parser per-input flags.

[mping]

+1 It would allow me to easily compare two jsons, side by side.

[markhu]

can someone build the binaries/installables that has this feature?

[bethesque]

I installed the mac version the other day, and the keys orders are not maintained.

[nicowilliams]

@bethesque New binaries have not been put up in a while. You will have to build the master branch from git.

[nicowilliams]

@svnpenn What's your Windows build procedure?

[bethesque]

It's not a huge priority for me, but if I can manage to build it easily, is there someone who can put the binaries up on the website for other people?

[nicowilliams]

@svnpenn Thanks. It'd be nice to have a non-autoconf, non-Cygwin makefile for use with MSVC... I might like to adapt Heimdal's Windows build some day...

[childnode]

unfortunately I can't see what https://github.com/stedolan/jq/commit/91cfc34ae40e2be359a6a09e956d84abf63f8448 changed ... behavior is still the same for me on jq-1.5-1-a5b5cbe

{
  "d": {
  },
  "z": {
  },
  "b": {
  }
}

becomes

[
  "b",
  "d",
  "z"
]

Update sorry, just saw https://github.com/stedolan/jq/issues/1109#issuecomment-193065863

js 'keys_unsorted'

[pkoppstein]

Update sorry, just saw #1109 (comment)

Yes, 91cfc34 was just the first step. Also note that it was not until 4a57b84 (30 Sept 2014) that to_entries respected the key ordering, and not until 7b81a83 (19 June 2017) that walk did so.