Should JSON files be key sorted?

[sumpfork]

I would like to enable the pre-commit JSON pretty format option so the card db source files are more standardized.

At the same time, I think I'd like to enable the alphabetical sorting of keys in those files. I'm less sure about this one.
Pro: It'd make reviewing something like #441 way easier. Right now it's very hard to tell what got removed, added, translated etc.
Con: It makes the files less intuitive to edit/browse as all the expansions in the card file will be mixed together.

What do you all think, too confusing for contributes if the cards are alphabetical and they get reordered back into alphabetical order by pre-commit (which many of them fail to install/run)?

@wvoigt @bszonye @nickv2002

[sumpfork]

For reference: #449.

[bszonye]

First, I definitely approve of the sorted imports with isort in the pre-commit. I use it in my own repos. (I personally prefer to use black & isort in --check mode for pre-commit. The pre-commit owner opposes that usage, but it's easy to get in a bind when external tools modify a file that you have open in your editor.)

[bszonye]

Second, it would definitely help if the output json files were in some kind of predictable order. I know that I've gotten confused every time that I've tried to sanity-check the output files after an edit. The first time, I thought that I had done something terribly wrong, because things moved around & made it look like I had changed stuff I hadn't meant to.

Alternately, perhaps the output files shouldn't be checked in? There are drawbacks to putting generated data into VCS, and this is one of them. Perhaps it's best to keep the input files in a convenient order for writing/reading, and to drop the runtime files from git? That would also eliminate problems with people getting confused about which copy to edit. Of course, that would require some extra packaging/installation code to generate the runtime data, and it'd still be a bit messy for editable installs, but I think it might solve more problems than it causes.

[sumpfork]

#449