Throw error if css function call used inside object in unsupported way

[dddlr]

What is this change?

The following code fails silently:

const someObject = {
    blue: css({ color: 'blue' }),
    red: css({ color: 'red' }),
}

const App = <div css={someObject['red']}>hello</div>

We add an error so that it no longer fails silently.

Why are we making this change?

We support this: (see #1321 )

const someObject = {
    blue: css({ color: 'blue' }),
    red: css({ color: 'red' }),
}

const App = <div css={someObject.red}>hello</div>

But we don't support this:

const someObject = {
    blue: css({ color: 'blue' }),
    red: css({ color: 'red' }),
}

const App = <div css={someObject['red']}>hello</div>

We should either:

• throw an error for someObject['red'] telling developers either to switch to someObject.red or switch to cssMap, or
• add support for someObject['red']

The first option is easier so I've done that in this PR 😅 but curious to hear your thoughts on whether we should in fact do the latter instead.

---

PR checklist

Don't delete me!

I have...

• Updated or added applicable tests
• Updated the documentation in website/
• Added a changeset (if making any changes that affect Compiled's behaviour)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 8c5e709

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[dddlr]

we probably don't need all of these... we can delete the ones that can't actually be triggered when we write the tests

[netlify]

✅ Deploy Preview for compiled-css-in-js canceled.

Name	Link
🔨 Latest commit	8c5e709
🔍 Latest deploy log	https://app.netlify.com/sites/compiled-css-in-js/deploys/67ce80fe8ef3390008f02e85

[dddlr]

the implication of course is that theoretically, you should only need cssMap if which set of styles you are using is dynamic, or otherwise not known until runtime.

For example, if you had some info styles and some warning styles, both of which are statically defined... but you didn't know whether to apply the info styles or warning styles until someone clicks on a button.

[liamqma]

Suggested change

	* - A usage
	* - A usage of the `cssMap` API from Compiled

[liamqma]

Can you please write a test case for it?

[kylorhall-atlassian]

Same as Liam — a test case or two and we're golden! If this throws errors, we should almost certainly fix them and let them block us—I think it's "safe" to land.