[SPIKE] Throw error if shorthand and longhand properties are mixed, or if invalid CSS properties are used #1747
+600
−12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is this change?
Spike the following potential feature:
As a bonus, I've also spiked the following feature, because it involves making mostly the same changes:
Why are we making this change?
While shorthand properties and longhand properties (e.g.
margin
andmarginTop
) are sorted deterministically in almost all cases due to #1700 , there are still some edge cases where this sorting cannot be preserved, causing shorthand properties to override longhand properties non-deterministically and vice versa.For example, if an app imports two packages that use Compiled, but the app does not use Compiled's Webpack or Parcel plugin, we cannot guarantee that the styles of the two packages will remain sorted (because we have no control on how the bundler sorts the stylesheets).
There are several solutions to this:
ax
to ensure that duplicate properties (e.g.margin-top: 5px
andmargin-top: 10px
) are removedHow are we making this change?
Build time error. We use a build time error, because build time and runtime are the only times where we can see all of the Compiled styles that will be applied to a given component. Doing this check at runtime is feasible (albeit a bit tricky due to the use of hashed class names) by extending the
ax
function, but ideally we'd like to not introduce any runtime impact if possible.Limitations
This DOES NOT work when using
styled
composition (which is deprecated anyway):BaseComponent
andComponent
are processed completely separately at build time.We could make some changes to
@compiled/babel-plugin
to try to make Compiled "aware" ofBaseComponent
when processingComponent
, but it would probably be a bit hacky. Something to explore perhaps.We could potentially extend
ax
to do a runtime check, but this would be even more hacky, as all that's passed toax
are the hashed class names. With this approach, we'd need to somehow go from the hashed class names back to the original CSS property names.PR checklist
Don't delete me!
I have...
website/
Todos:
styled
usagescss
usages (includingcss
composition)styled
usages (props, dynamic styles...)cssMap
ClassName
xcss
styled
compositionfont
(shorthand and longhand mixing is required for the Atlassian Design Systemfont
tokens)