Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Updating
@stitches/react
to fix a number of issues with the library with later versions of Typescript.@Mhoog and I have been through the wringer over the past few weeks trying to resolve some type issues with
@atom-learning/components
and@stitches
in particular, resulting in this need to update@stitches
to the latest published version (a beta).I've written some of the steps that we went through to provide a bit of context, but it included a fair amount of trial and error testing, patching local versions of the packages, whilst also trying to resolve local TS issues with our codebase, so please let me know if you want any more detail on why we did certain things, but hopefully, we concluded with a relatively simple fix.
The initial issue we hit was with how
@stitches
accessed types from modules that weren't exported from the moduleThis was flagged sporadically across
styled()
and standardBox
,Flex
, etc. components, and we've also had this a couple of times in our own codebase. @Mhoog fixed this in #454The next issue was types missing altogether from
@atom-learning/components
&@stitches
, which required a change to TS module resolution"node16"
to"node"
, alongside an upgrade to TS itself. There are a whole heap of weird compatibility issues with the various ways that TS resolves modules and the requirements that it has with each condition to return the correct files. So TS needed an update and the type imports needed to include the relevant extension. This was fixed in this PR to@stitches
stitchesjs/stitches#1084The final issue, now we'd upgraded to TS 4.9 was with
@stitches/react
s use of symbols. stitchesjs/stitches#1082Thankfully that fix went into the beta release, so the only remaining issue was our use of
inset
as a key in our@stitches
utils
🤷For some reason, in this updated version of
@stitches
, the keyinset
produced this TS error. I can only assume that somewhere in the update they've changed how custom utils and standard CSS properties overlap, and produce an error if any key inutils
matches a standard CSS property. https://developer.mozilla.org/en-US/docs/Web/CSS/insetWe don't use
inset
too much in the codebase, and unfortunately, we can't use it natively until we drop Safari 12/13, so I have just removed the custom util and replaced it inline withtop: 0; right: 0; bottom: 0; left: 0
.I've probably forgotten a few things to mention, but that's broadly how we got here.