Promote is-prop-valid, memoize, utils, sheet, etc to 1.x

[FezVrasta]

There are a lot of @emotion/* packages with a version lower than 1.0.0. This makes package managers such as npm and Yarn treat them as incompatible within feature and patch versions of themselves (0.x.x).

• @emotion/hash
• @emotion/is-prop-valid
• @emotion/memoize
• @emotion/serialize
• @emotion/sheet
• @emotion/stylis
• @emotion/unitless
• @emotion/utils
• @emotion/weak-memoize

The problem with this situation is that we end up with a lot of duplicate versions of the same package, because of this versioning constraint.

For example, in one of my projects, I have 3 @emotion/is-prop-valid versions, because some packages require ^0.8.2, some ^0.6.1 and others ^0.7.3. In all these cases, the ^ is ignored by the package managers, so the final bundle ends up shipping 3 versions of the same package.

Here some context about the 0.x versioning flaws:
semver/semver#221

Is there any reason of why we are using 0.x versioning for these packages or could we bump them to 1.0.0?

[Andarist]

Not saying that a change regarding this wouldn't be good, I'm curious though - how do you end up with multiple versions? Which different packages require those?

[FezVrasta]

In my case I have a very big project that is still using Emotion 9 along with Emotion 10. We are converting stuff to Emotion 10 but meanwhile we are in this situation.

[Andarist]

This wouldn't help you with deduplicating emotion@9 dependencies though, right? You'd still use old pre-v1 versions there.

[FezVrasta]

Yes but hopefully that wouldn’t be a problem with Emotion 11 at least

[Andarist]

Some of those packages are going to be already upgraded together with v11, for the rest I've created a PR and some I have left untouched (reasoning is written down in that PR).

Let's close this for housekeeping purposes and just continue this under that PR if needed.