Open armanbilge opened 3 years ago
I was daydreaming about this and realized there was some subtlety I missed when I first wrote this up. Unlike API reports, which we want re-generated for every PR so we can compare the diff, we actually do not want to re-generate MiMa exclusions because these should be based on the last stable version. Generating exclusions based on the current code is self-serving and would let you sneak all kinds of bad stuff in ;)
With this in mind: MiMa exclusions should definitely be generated into files (like the API reports) and my idea above about dynamically loading the exclusions should be tossed. Furthermore, re-generating these exclusions should not happen in a prePR
step, but only after releasing a new version of scala-js-dom.
As proposed in https://github.com/scala-js/scala-js-dom/pull/380#issuecomment-905130204.
The idea is to use @japgolly's API report machinery to automatically generate exclusions for known binary-compatible changes for facades as delineated in https://github.com/scala-js/scala-js-dom/pull/461#issuecomment-894829615. This would enable us to use MiMa without the headache of an overwhelming number of false-positives. Furthermore, I think this would be a significant step towards an auto-generation scheme as described in https://github.com/scala-js/scala-js-dom/discussions/487#discussioncomment-1185706.
I know MiMa exclusions can be specified via files (this is how Akka projects manage theirs) and also in the SBT build. The former strategy is very compatible with the API-report generation scheme, but requires an extra
prePR
step and CI overhead to keep this in sync with the source. If it's not too ambitious, I wonder if during the MiMa check the exclusions can be generated programmatically instead of read from a (programatically-generated) file. If it works, that would be a significant simplification and remove a burden from both maintenance and contribution.