Use data classes is a bad pattern for public APIs in libraries: https://jakewharton.com/public-api-challenges-in-kotlin/
TL;DR: If you expose data classes is too easy to create binary-incompatible bytecode in next versions of your library.
We can add a rule that checks for all the data classes and ensure that they are private or internal.
We should add a flag too to allow data classes in certain packages. And here I can think about two different options:
ignoreInternalPackage and ignore all the classes inside a package *.internal.*ignorePackage and allow to set any packages.I like the first a bit more because it forces the use of internal package. That it's kind of a standard solution. But the second gives more freedom to the user, and that's good too.
For sure, this rule should be disable by default because it only have sense for library developers. If you are creating a final application you are not going to have any binary-compatibility problem.
Good idea!
I created a draft with this new rule. But we need to think about the flag to ignore some packages. Which option do you like more?
Why no use the second option and have *.internal.* as default?
Most helpful comment
Why no use the second option and have
*.internal.*as default?