Closed 5t3ph closed 3 months ago
Hello, I work with Stephanie and was wondering if this issue has been triaged yet or if we can provide additional information to help come to a resolution. Thanks!
In the serializer README, it states "your rules get included in the snapshot" so we were wondering if we were missing an option, or were misunderstanding the intended outcome of the serializer. If it's not possible to fail on a CSS change, is there another method to have that behavior that you're aware of?
Hey, it's misunderstanding, let me correct the README file.
The goal of the serializer is to remove classes generated by Griffel, that's it 🐱
If it's not possible to fail on a CSS change, is there another method to have that behavior that you're aware of?
Well, then don't use the serializer and have snapshots with classes, it will fail on changes 😊
However, it's not the best option as class generation is considered as internal API - we can change it in future to get something more effective and accidentally fabc
can become fbcd
🥲
Our suggestion as Fluent UI team is to use visual regression tests for CSS related changes due the following reasons:
.toHaveStyle()
are not reliableWe adopted that practice in Fluent UI & recommend it for consumers. We don't plan to add additional functionality to the serializer now.
Thank you for the detailed explanation!
I'm on a design system team at Microsoft leveraging Fluent v9. We were exploring using the serializer, but would prefer snapshots still fail if there is a CSS change so we can verify that it was an intended change.
In the serializer README, it states "your rules get included in the snapshot" so we were wondering if we were missing an option, or were misunderstanding the intended outcome of the serializer. If it's not possible to fail on a CSS change, is there another method to have that behavior that you're aware of?