it looks to me like this call to toText was simply incorrect whilst calling mapWithKey, but it is hard to tell across different versions

This fails on older lts versions as Config from Data.Yaml.Pretty is defined as:

-- |
-- @since 0.8.13
data Config = Config
  { confCompare :: JSONPath -> Text -> Text -> Ordering -- ^ Function used to sort keys in objects
  , confDropNull :: Bool -- ^ Drop null values from objects
  }

This uses JSONPath which was only exposed from Data.Aeson.Types in 1.4.5.0. Do we want compatibility with those lts versions?

I could not for the life of me figure out where the Key data constructor comes from. May I suggest doing something to help make that obvious?

@treeowl I made the aeson types explicit - if you'd prefer I make them qualified instead then I'm happy to oblige.

Personally I think a qualified use of the Key data constructor would be more obvious. I still can't find it, but maybe it's just me? Where does that come from?

I think mapWithKey is only introduced in aeson-2.1.0.0, so this needs so attention too, otherwise versions between 2.0.0.0 and 2.0.3.0 will also error. The stackage lts-19.33 includes aeson-2.0.3.0, so would be a good to add to the test matrix.

@treeowl I realized the explicit imports cleared up nothing, so I made them more explicit - let me know if that helps.

@jonathanlking I gave this a go - quite a pain and I am not confident it is right.

@phadej - would be helpful if you have a moment to look at this in case there is something more sensible to be done.

Definitely better. Qualified would be clearer still, but it's not worth too much clutter.

@treeowl I made them qualified too, don't think it is much harm and if it improves the readability in the longer term then it is worth it imo

@Boarders I agree it’s nasty! I’m not sure about functional correctness, but you could be confident that things compile if you added more lts versions (i.e. jonathanlking@5619707). I don’t really see any downside to this, as they all run in parallel and GitHub actions are free?

It would be nice to get some feedback on what we want to do regarding older versions to move this PR forward. I'm happy to take @jonathanlking's suggestion on adding lts versions - what would be good coverage?

I commented on the original issue that this had already been resolved: #207 (comment). This PR is no longer mergeable because the relevant lines have already been adjusted.

Makes sense, thanks!