-
Notifications
You must be signed in to change notification settings - Fork 2
Description
Feature Summary
We should avoid that 2 classes define the same CSS rule, as by design we cannot make assumption on CSS specificity and order.
Rationale
If an element has tho classes operating on the same rule we cannot predict which one will be applied e.g.
.myClass {
electrons: (margin_s, margin_l);
}if the margin will be s or l is not predictable and it shouldn't be as we are breaking the concept of composition here in favor of the one of overrides.
.scrollableRoot {
electrons: (margin_s);
}
.myClass {
composes: scrollableRoot;
electrons: (margin_l);
}in this case scrollableRoot is already defining some margin and we do not know if .myClass will result in an s or l margin.
Proposed Changes
Ideally we should spot these issues during the atom build. But could also be a separate visitor to avoid performance bottlenecks, and can be run only on the production build.
We could use a visitor to go through the exported atoms and check using postcss and the generated bundle if any exported class string is applying the same css rule twice or more.