Dmitrii Kovanikov

In that case, I can propose the following plan: - [ ] Implement `logBuilder* :: LogAction m Builder` family of functions - [ ] Change `Msg` and `SimpleMsg` types to...

To be more backwards-compatible in the new version, we can replace only internal types for formatting with `Builder` and keep functions that take `Text`. Those functions will be deprecated in...

@HuwCampbell I think this is a very important feature to have. And implementing optional arguments would increase `optparse-applicative` a lot. It's a huge deal! While developing tons on CLI tools...

Multilib packages don't really replace the grouping of similar packages under the same namespace as versioning is more difficult for them (you can't change version only for a single package,...

@hvr Thanks for the information! This makes sense. Issue #5531 looks similar.

I would encourage to not introduce separate `common-executables` stanza. This introduces another layer of unnecessary complexity. I think nothing stops `common` stanzas from being **typed** but still support different stanza...

In @kowainik we're using [our own git/GitHub workflow](https://github.com/kowainik/org#version-control-system). But in simple words, we do `Squash and merge` for each PR. So I can recommend this approach, it works exceptionally well...

If you want to have a smaller example, you can have a look at this repository: * https://github.com/chshersh/ghc-plugin-non-empty This project uses GHC 9.2.3 and, apparently, Hackage Docs builder still uses...

This is known issue. And this is not a bug of `importify`. This is because of bugs in `haskell-names` library: https://github.com/haskell-suite/haskell-names/issues/96 I don't think this can be fixed w/o dirty...

Thanks for your feedback, @vrom911! I agree, it would be really great to run `importify` over single files or even `stack-script` projects. This is known issue, so I'll rename the...