changeset-bot[bot]
commented
6 months ago 🦋 Changeset detected
Latest commit: f1fe7766f3a1c534373fd5d6ec6336ebe5ff459b
The changes in this PR will be included in the next version bump.
This PR includes changesets to release 7 packages
| Name | Type | | --------------------------------------------------------- | ----- | | @compiled/react | Minor | | @compiled/parcel-optimizer-test-app | Patch | | @compiled/parcel-transformer-test-app | Patch | | @compiled/parcel-transformer-test-compress-class-name-app | Patch | | @compiled/parcel-transformer-test-custom-resolve-app | Patch | | @compiled/parcel-transformer-test-custom-resolver-app | Patch | | @compiled/parcel-transformer-test-extract-app | Patch |Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
[example for @itsdouges to review into https://github.com/atlassian-labs/compiled/pull/1636]
We don't actually need the generic value for this to be valuable, this should block it so an
@compiled/react.cssMapwith conflicting values is disallowed, but also can allow prop-level restrictions (if we want).This is by moving
CompiledPropertyDeclarationReferenceto not be optional as that object seemingly messed something up as| CompiledPropertyDeclarationReferencewas always "truthy" (if that makes sense).However, this removes the functionality for inline
xcssand requires acssMapor futurecss(?) to exist..which is probably fine.This has one remaining scenario not erroring (if I fixed the other inline
xcss={{ … }}object tests), but it does error somewhere in the stack, and this is because a cssMap-level type error is typed differently than a non-erroring cssMap?