Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reorganize @emotion/utils types #3076

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

JeromeDeLeon
Copy link

@JeromeDeLeon JeromeDeLeon commented Jul 15, 2023

What: #3075

Why: To fix inconsistent type from #3075

How: Reorganizing the @emotion/utils by moving the types to the proper package.

Checklist:

  • Documentation n/a
  • Tests
  • Code complete - n/a
  • Changeset

I'm not able to fix the constructor issue. When I tried to convert it to interface /types, it complains as it was either being merged to StyleSheet DOM type or a duplicate name.

@changeset-bot
Copy link

changeset-bot bot commented Jul 15, 2023

🦋 Changeset detected

Latest commit: 67518ed

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

This PR includes changesets to release 6 packages
Name Type
@emotion/cache Minor
@emotion/css Minor
@emotion/react Minor
@emotion/serialize Minor
@emotion/server Minor
@emotion/utils Minor

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
Copy link

codesandbox-ci bot commented Jul 15, 2023

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.

Latest deployment of this branch, based on commit 67518ed:

Sandbox Source
Emotion Configuration

@JeromeDeLeon
Copy link
Author

JeromeDeLeon commented Jul 15, 2023

@Andarist I ended up touching some .js files but flow complains about the type not being declared and has no idea how to fix them 😞

I realized that in flow, you must declare types in .js, hence why I saw repeated types both in .js and .d.ts. Once I reverted, everything went fine now.

@JeromeDeLeon JeromeDeLeon force-pushed the chore/reorganize-types branch 2 times, most recently from 0b9529c to bf56fb8 Compare July 15, 2023 08:08
[key: string]: string | true
}
registered: RegisteredCache
sheet: EmotionStyleSheet
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only thing I can think of that would solve the constructor issue, let me know if you don't want it or if you have any thoughts

@JeromeDeLeon
Copy link
Author

JeromeDeLeon commented Jul 15, 2023

Noob question, how would I be able to test this on my package locally? I just want to make sure that everything I did here works 😅

The test seems to tell me that everything is fine

I downloaded the build via https://pkg.csb.dev/emotion-js/emotion/commit/1776c402/@emotion/* and managed to remove all types issues

':hover': css`
color: hotpink;
`
})

// $ExpectError
css(() => 'height: 300px;')
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Andarist Are there reasons why this and below it are not allowed even though they worked?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this css call doesn't run in any kind of "context", we don't have any arguments to give to this function so we don't allow functions to be passed here

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I'm guessing, even though it works in nature, there's no point in doing this as it doesn't run in any context?
I'm looking for reasons why we do not allow these things in TS due to type complaining, but it's working just fine.

| CSSProperties[K]
| Array<Extract<CSSProperties[K], string>>
}

export type CSSPseudos = { [K in CSS.Pseudos]?: CSSObject }
export type CSSPseudos = { [K in CSS.Pseudos]?: CSSInterpolation }
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • a test that allows CSS composition but not in TS
  • a test that allows false value but not in TS
  • a test that allows child selector array but not in TS

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks legit but I will have to reexamine this more closely later.

Comment on lines +16 to +18
| null
| undefined
| false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I guess those were added to account for "a test that allows false value but not in TS"?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but a weird thing happened, I managed to build my own serializer based on the implementation but using js-beautify like beautify.css() instead of using @emotion/css-prettifier.

When I used it and passed null like css({ textAlign: null }), it created a weird selector like .emotion-0 textAlign {} but when I switched to @emotion/css-prettifier, it removed it.

The @emotion/css-prettifier also removes the empty selector like .emotion-0 {} which I guess does the same thing hence why in the test we're not seeing these weird things.

It's not an issue as I can just use that lib you guys already have but just a weird thing that it only happens when it's null

Comment on lines 3 to 4
import type { SerializedStyles } from '@emotion/serialize'
import type { RegisteredCache, EmotionCache } from '@emotion/cache'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't import from other packages here because we don't depend on them. This is also true at type level - even if we still don't import anything at runtime.

I'd keep the existing types here (to avoid breaking changes) but I'd deprecate them in favor of the proper ones exported by specific packages). In the future, we should just remove export from those local types here. This way we'll be able to depend on TS structural type system without introducing any dependencies to this package.

cache: EmotionCache,
serialized: SerializedStyles,
cache: EmotionStyleCache,
serialized: EmotionSerializedStyles,
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Andarist This is what I ended up doing otherwise, they would be incompatible to each other.

@@ -2,6 +2,7 @@
"extends": "@definitelytyped/dtslint/dtslint.json",
"rules": {
"array-type": [true, "generic"],
"semicolon": false
"semicolon": false,
"no-redundant-jsdoc": false
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Andarist I tried all of these options but didn't work so I had to do this instead https://palantir.github.io/tslint/usage/rule-flags/

@JeromeDeLeon
Copy link
Author

@Andarist Is there anything blocking this PR? I'm happy to address them 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants