tighten up cssMap type

[liamqma]

Further tighten up cssMap type to prevent some invalid usages.

Examples
No Arrays

const styles = cssMap({
   foo: [{ color: 'red' }]
})

No tagged template

const styles = cssMap({
   foo: `
     color: red
   `
})

No arrow function

const styles = cssMap({
   foo: {
      color: (props) => props.a ? 'red' : 'green'
   }
})

Only string and number are valid CSS values. No boolean/undefined.

const styles = cssMap({
   foo: {
      color: possibleUndefined && 'red'
   }
})

[changeset-bot]

🦋 Changeset detected

Latest commit: 8e057a5

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 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-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

[dddlr]

I wonder if there's a way to ensure that the user can't nest objects indefinitely or with invalid keys, e.g. stuff like

const styles = cssMap({
  danger: {
      veryDanger: {
        color: 'red',
      }
  },
})

without affecting valid use cases such as @media queries

[dddlr]

I'm not at my laptop so I can't test this out, but it does seem like there's nothing stopping the user from doing stuff like

const styles = cssMap({
  danger: {
      veryDanger: {
        lotsofDanger: {
          evenmoreDanger: {
            spectacularDanger: {
              color: 'red',
            }
          }
        }
      }
  },
})

[liamqma]

yea, we've to allow it unless we impose stricter types.
The problem is that we don't know if the object key is a selector.
In the below example, we don't know if header is a variant name or a selector.

const styles = cssMap({
  success: {
      header: { // Is it <header /> or a variant name? 🤷‍♂️
         div: {
             color: 'red'
         }
      }
  },
})

I thought about disallowing targeting selectors completely, but I think disallowing it is too specific to Atlassian CSS standards.

[dddlr]

I see, thank you for clarifying 👍

[JakeLane]

I think we can do better here, it may be worth a play with the structure

I've made a quick spike based on vanilla extract types https://github.com/atlassian-labs/compiled/pull/new/css-map-type-spike

In https://vanilla-extract.style/documentation/styling/#media-queries, they specify some bounded keys that allow the types to be much stricter

[dddlr]

Todo:

• Rebase
• Remove pseudos that we don't recommend using
• Fix flow errors 😢
• Double check type checking that nested selectors still work, as long as they're all targeting the same element
• Unit tests - thoroughly test both StringLiteral and Identifier
• Update VR tests
• Investigate why having an empty object as a variant value gives an unhelpful error
• Replace throw new Error with buildCodeFrameError
• Make a PR updating website documentation
• Update changeset to minor, document new selector restrictions and at-rule changes in changeset

[itsdouges]

Would be great to reduce the total amount of declarations. So instead of allowing both ::active and :active we settle on one.

[dddlr]

Ah good catch, didn't notice the duplicated pseudo-elements (:before/::before, :after/::after, :first-letter/::first-letter, :first-line, ::first-line)

[liamqma]

Looks good. I wanted to give approval but notice I cannot approve my own PR 😬.

[dddlr]

all good @liamqma i've approved it now (despite most of the changes being from myself 😆 )