Upgrade to MUnit 1.0.0-M6 #223
Conversation
My bad, this is not a regression but a deliberate breaking change. See scalameta/munit#539. |
| .settings( | ||
| name := "munit-cats-effect", |
There was a problem hiding this comment.
We should make sure to register a Scala Steward migration for munit-cats-effect-3 -> munit-cats-effect.
|
I think it would be great to start publishing milestones against this as soon as possible. There are quite a few improvements, and that way we can be sure that everything is working correctly. |
|
Gratefully tagging @valencik for review 😁 |
| @@ -1,77 +1,24 @@ | |||
| ThisBuild / tlBaseVersion := "1.0" | |||
| ThisBuild / tlBaseVersion := "2.0" | |||
There was a problem hiding this comment.
Are we really want to do a new major release based on the fifth milestone?..
There was a problem hiding this comment.
Bumping the base version doesn't mean a new major release, it means we are starting the 2.x series of development that is not compatible with any 1.x release. I propose we publish this PR as 2.0.0-M1
There was a problem hiding this comment.
There was a problem hiding this comment.
Hmm, I just was confused with this reference to 2.0.0.
There was a problem hiding this comment.
Haha yes, we always debate the correct deprecation version for http4s too :) I don't really care, I will happily put whatever you want there.
| scalaJSLinkerConfig ~= (_.withModuleKind(ModuleKind.CommonJSModule)) | ||
| ) | ||
|
|
||
| lazy val ce2 = crossProject(JSPlatform, JVMPlatform) |
There was a problem hiding this comment.
If we decided to make EOL the whole library ("munit-cats-effect-2"), I argue it should be described in docs. As well as changing munit-cats-effect-3 -> munit-cats-effect. What do you think?
There was a problem hiding this comment.
Yes, it should be described in docs. But if we make those changes in this PR, then it will go live as soon as it merges even before official release. Maybe should make a new branch for me to target my changes to, instead of main?
There was a problem hiding this comment.
I think we already can slice changes on removing CE2 support into another PR and merge it as soon as possible (because no things we should do after it) 👍🏻
There was a problem hiding this comment.
Good plan, I will prepare it shortly.
There was a problem hiding this comment.
Aww. Probably I was wrong here. I was thinking we want to deprecate the whole library. Because we integrate CE support to MUnit, not vice versa. If we encourage investing in migration to CE3, let's do it at max 😆
There was a problem hiding this comment.
Haha, I see. Actually that was how this library started but it is better it remains independent. Origin story:
There was a problem hiding this comment.
Okay, but why not deprecate the CE2-based library? Speaking as one of the http4s maintainers, it'd be totally fine. Because I'm confident, here we integrate precisely CE support.
There was a problem hiding this comment.
I think we should just EOL 1.x when 2.x is released. And 2.x won't support CE2 at all.
There was a problem hiding this comment.
Wow this really simplifies things! Considerably less special casing for ScalaJS which is cool.
I also published this locally and tested that one of my favourite fixes to munit v1.0, filtering suites no longer runs their fixtures, works as expected: valencik/munit-fixture-suite-filtering#1.
Thanks a bunch for writing this, I'm excited to use it :)
|
Can't wait to use this, thank you for your effort @armanbilge! |
Thanks for mentioning this. Actually Scala.js shouldn't need any special casing now, there was some dead code I forgot to delete :) |
|
Is there anything holding up this PR being merged? And does anyone know the 1.0.0 release plans of Munit? |
|
I'm going to merge and release a milestone. |
Closes #147.
Fixes #172.
Closes #208.
There is currently failing test due to a regression in MUnit.