Let css prop attachment be distributed over union types.

[ENvironmentSet]

What: Let css prop attachment be distributed over union types. So that branches with className prop are extended with css prop.

Why: Some components may accept className prop conditionally. For example, Link of wouter does. Emotion skips these cases, however, and does not add css prop in anywhere. As far as I know, there is no runtime or compilation-time problem stopping us from supporting these kind of components. Thus I propose this change to enhance expressiveness of the library.

fixes #3185

How: Made LibraryManagedAttributes be distributed over a prop type in cases it is a union.

Checklist:

• Documentation "N/A"
• Tests
• Code complete
• Changeset

Should I add test cases for this change? Please let me know if you need.

[changeset-bot]

🦋 Changeset detected

Latest commit: f181c72

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

This PR includes changesets to release 1 package

Name	Type
@emotion/react	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

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[Andarist]

We'd need some type-level tests to take in this change

[ENvironmentSet]

Indeed, I'll add some. Would you please give me a guideline to add type level tests or example to refer to? I could not find either an example of type-level test or a setting relevant to it in emotion repository.

[Andarist]

You can add them here at the bottom of the file: https://github.com/emotion-js/emotion/blob/e819f9c39c4485997ce97fd2cfd330be8114e0f8/packages/react/types/tests.tsx

[ENvironmentSet]

Thanks, I added a test. Let me know if you need more.

[ENvironmentSet]

It seems dtslint compares type too strictly. I'll find other ways to express validity of the implementation.

[Andarist]

This is like a unit test. I am more interested in an integration test for this change. How did you come across this to be an issue? Maybe it was related to code like this?

type DiscriminatedClassNameSupportProp =
  | {
      variant: "foo";
      className?: string;
    }
  | {
      variant: "bar";
    };

function DiscriminatedClassNameSupportComponent(
  props: DiscriminatedClassNameSupportProp,
) {
  return null;
}

<DiscriminatedClassNameSupportComponent
  variant="foo"
  // this should be OK
  css={{ color: "hotpink" }}
/>;

<DiscriminatedClassNameSupportComponent
  variant="bar"
  // this shouldn't be OK
  css={{ color: "hotpink" }}
/>;

[ENvironmentSet]

Yes, that was my case. May I add tests like that?

[Andarist]

Yes. Please replace the tests you have here with something closer to the one above :)

[ENvironmentSet]

Sure. I'll update PR tonight. Thank you for comments!