Thanks!

It looks good and sitting around, so let me try a review:

• The code looks clearly correct—I have a bit more trouble reading the parser, but this clearly outputs the syntax described in f10d1f7.
• Looking at the history suggests this is not intended. Those instances were consistent as of 038ec35, and made inconsistent by f10d1f7 without an explicit rationale. I expect the ToJSON instance is just currently unused. Did you notice any use of the instance producing the incorrect output? Or is the entire config prettyprinting dead code?
• Ideally, we'd also need a test to ensure the instances are inverses (in both directions, at least for correct JSONs). Would you mind providing that? But if you're short on time, I'll rather merge a bugfix without tests than leaving a bug in.
• I'm running the integration tests by hand since they're not yet in the CI (take too long for Travis) with stack test --flag stack:integration-tests, just to be extra-sure.

My integration tests passed, hence merging. If you also contribute tests, send a PR and I'll fast-track the merge! Thanks!

Thanks! I'll see what I can do about those tests.

I did notice the bug by using the ToJSON instance. I ran a script to modify a stack.yaml file, but the output file was invalid. So I discovered this bug not by using stack as a program, but as a library.

I am not sure how to proceed about the tests.

One way could be having a golden value that can be then printed to file and read back, and then check if the final value matches the original.

Other way would be doing a QuickCheck based test, requiring an Arbitrary instance for some types. This will provide more solid tests, but I'm not sure if we even want to do this.

In the other hand, the test directory contains two directories: integration and package-dump. None of these seem to be the place for round-trip tests.

One way could be having a golden value that can be then printed to file and read back, and then check if the final value matches the original.

Other way would be doing a QuickCheck based test, requiring an Arbitrary instance for some types. This will provide more solid tests, but I'm not sure if we even want to do this.

I'd go the first way—but not to a file, just to Text/ByteString and back, in both directions, and use a few golden values to cover the different cases.
Values x should ideally cover various cases of PackageLocation (PLFilePath, PLRemote RPTHttp, PLRemote RPTGit and PLRemote RPTHg).
QuickCheck is nice but takes more work, and given the code I assume one value gives enough coverage as long as parseRequest is correct for its use. (Though it doesn't do exactly what I'd want, see #2431).

In the other hand, the test directory contains two directories: integration and package-dump. None of these seem to be the place for round-trip tests.

I think you want src/test (yes, that's confusing), in particular src/test/Stack. I found roundtrip tests in src/test/Stack/StoreSpec.hs. EDIT: they use SmallCheck so I'm not sure they're the perfect example—your call.

Oh, sure, writing the bytestring to a file is pointless. I don't know what I had in mind.

No problem, happens to all of us! 😄