👋 @CrystalSplitter
Thank you for raising your pull request.
Please make sure you have followed our contributing guidelines in DEVELOPER.md. We will review it as soon as possible!

Reviewer: Please verify the following things have been done, if applicable.

• A file has been added to changelog.d/
• "Configuration > Available options" section in README.md has been updated
• "Configuration > Specifying configuration" section in README.md has been updated
• Tests have been added

Hold on, parsing issue.

Error in $['column-limit']: parsing ColumnLimit failed, expected String, but encountered Number.

May have broken it somewhere in my fixups...

@CrystalSplitter the adtParseJson implementation, I think.

Also, the tests apparently dont test that function... I'll have to think about how best to test it

The underlying issue here is that column limit can both be a String (none) and an Int during parsing.

Some solutions:

• A real quick solution to this would be that 0 or lower is none. This is originally what it did at the very beginning, but it was requested that Gustavo change that. I think this option is fine, though weird from a user perspective.
• Another solution is make a somewhat hacky parser that returns both the string "none" and an integer as a raw string. This is fine from a user perspective but weird for implementation.
• And another solution is to write in the documentation that the integer has to be wrapped in quotes. I dislike this option.

Or just parse it directly?

parseJson = \case
  String "none" -> pure NoLimit
  Number x | Right i <- floatingOrIntegral x -> pure $ ColumnLimit i
  _ -> fail "Invalid ColumnLimit"

It'll slightly duplicate the adtParseText implementation, which I think is fine.

Done, but I had to include scientific in the depends. I noticed that there was a test that broke with that, so I patched that as well. I'm unsure if that was the right move, though.