Usually, I'm all for MiMa, and I enable it in all the repos. But it is really not good at checking JS facade types. It has no idea what is or isn't binary compatible from the point of view of facade types. Since scalajs-dom is almost exclusively filled with facade types, I think enabling MiMa will cause much more pain than benefit.

I see, so if I understand correctly, binary compatibility is important here, it's just that MiMa flags up a lot of false positives?

Yes, that's right.

Then at least for me, MiMa is still a useful tool for catching bincompat issues even if there will be a lot of false positives ... maybe I'll change my mind after trying it. But if @japgolly isn't worried, then that's fine.

It has no idea what is or isn't binary compatible from the point of view of facade types.

Do you mind expanding on this a little bit i.e. what makes a facade different? I worry there's something here I'm not understanding.

MiMa checks binary compatibility at the class file level, following the JVM linking requirements. For Scala classes, this is a very good model for Scala.js compatibility as well, because sjsir file compatibility is very close to class file compatibility. However, for facades, sjsir compatibility is a lot more permissive. Here is a non-exhaustive list of changes that would be binary incompatible for Scala classes, but that are compatible for JS facade types:

• Removing a member
• Changing the type or signature of a member
• Adding a field in a trait
• Adding an abstract member in a trait

Most changes in the DOM facades belong to one of those, since it is often fixing types and adding members in classes/traits. They would be flagged as false positives.

The following are changes that are indeed incompatible in both formats:

• Removing a trait/class/object
• Changing a class into a trait or vice versa

Aha, thank you for explaining in detail. That is much more permissive than I realized. I agree, we don't need MiMa here.