あくまでも「新たにasync版のほうをつくるなら、できれば改善して欲しい」程度で、今すぐ現状のやつの互換性を壊してまで変えたいほどじゃない
- コード生成部分とsbt plugin部分を分けたのはいいが、そのせいで似たようなsettingのオブジェクトが2つ出来てしまい、設定増やすとき微妙に面倒なので、改善できるなら改善したい(コード生成部分とsbt plugin部分を分けること自体は悪くないと思う)
project/scalikejdbc.propertiesから読み込むのとproject/Build.scalaで設定する(そちらでしか設定できない)ものが混ざってて微妙なので、なんかしら整理したい- 互換性壊さずに抽象化というかカスタマイズ可能にするために、こういうこと https://github.com/scalikejdbc/scalikejdbc/pull/370/files をしたが、そもそも互換性壊していいなら、同じ方法でtraitを切り出すにしても、もう少し違うメソッドになると思う
- とにかく
CodeGenerator.scalaのファイルが大きすぎるので、もっと分割 CodeGenerator.scalaにファイル書き込みのメソッドあるの微妙なので、CodeGenerator.scalaは基本的に String を生成して返す役割だけをさせたい(ファイルに書き込むのは別のクラスで)- その他色々もっと細かく拡張やカスタマイズ可能にしたい
- scripted test時間がかかりすぎるので、もっと簡単に単体テストできるなにか
object SbtKeysが分かれているのはいいような悪いような微妙なところ(Pluginを継承したやつの中に書けば、build.sbtの中ではデフォルトでimportされるが、この場合されないので)- sbtのKeyの種類も、現状そんなに大きな問題はないが、新たにつくるなら、今と全く同じではなくもう少し整理のやりようはあるかもしれない？
- そもそも、そろそろAutoPlugin(sbt0.13.5以降の機能)でいいかも？
scalikejdbc.mapper.SbtPlugin内部で例外投げてるところ、composableじゃないというかたまに不便なときがあったので、最終的に例外投げるにしても、途中はEither使うなどしてもいいかなぁーと個人的に思った- バイナリ互換を維持する(少なくともmimaでチェックする)なら、最初からもっと維持しやすいように工夫しておくべき
- 可能なら、コード生成された後のコードを、自動でいい感じにフォーマットできる仕組みを入れる？