Multiple versions of @internationalized/date package

[alirezamirian]

We faced an issue with date components, which seems not specific to us, and we are wondering if you have also faced the same issue and what your thoughts about it are.

Working with date components, one needs to install and use @internationalized/date package to import the date classes such as CalendarDate. The implementation of those date components (e.g. @react-spectrum/datepicker) also imports those classes. If those imports are resolved to different installation of @internationalized/date, it leads to the TS error below, which is caused by this trick to allow for nominal type checking instead of structural:

Have you encountered the same issue? We have thought of the following solutions so far:

• Re-export stuff from @internationalized/date, from our component library, so that users of our library don't need to install it separately.
• Make dependency to @internationalized/date a peer dependency of our component library, instead of a dependency.
• For @internationalized/date to avoid the need for nominal type checking, and let the differences between types reflect on the structure.

[snowystinger]

We have both encountered and not encountered this. We maintain, much like React, that you should only resolve to one version of any of our packages. We rely on React Context a lot, and if you have multiple versions of our packages, then you will run into problems. So we know that multiple copies of our packages will cause issues, but so long as you resolve it to one version, as you have pointed out, then there are no issues.

You could re-export from our packages, but then your users are possibly beholden to your update cycles or they may inadvertently use their own copy of the package and then you're back in the same boat.

We have dependencies on the @internationalized/date packages in our react-spectrum packages, so I don't think having it be a peer of yours will be quite right. As long as you include it as a dependency with a range for the value, you should be fine.

I don't quite understand the suggestion in your last point.

NPM can try to be a little too smart when it comes to frontend, and it will frequently try to install multiple copies of packages so as to introduce the fewest code path changes possible. This is great for servers, however, for client code, it's usually unwanted. You may need to use tools like dedupe or resolutions in order to get back to a single copy of a given package. You can also delete node_modules and your lock file for the nuclear option.

[alirezamirian]

Thanks for your detailed response.
Yes, we are aware of the issues related to multiple installation of packages that use module-level global variables or React Context. In fact we have specific instructions to troubleshoot those issues and dedupe dependencies. IMHO, we lack a proper way of instructing package managers to treat a package as singleton and only allow one installation of it. But that's a separate discussion. This particular issue though is not exactly a case of that.

There's no runtime issue in multiple versions of @internationalized/date being loaded at runtime, and the issue is merely a type error, caused by the mentioned trick, to force typescript do nominal type checking instead of structural. That's why making @internationalized/date a peer dependency could be a possible solution for us, despite it's a normal dependency in many react-aria|stately packages. i.e. we only need to make sure the props interface for our DatePicker component imports things like CalendarDate from the same location than the users of our library do, which would be guaranteed by having @internationalized/date as a peer dependency. Though it would be nice not to make it a peer dependency just to work around this issue.

I don't quite understand the suggestion in your last point.

The mentioned trick for nominal type checking is to add a #type private field to classes like CalendarDate , so that objects of other types (e.g. ZonedDateTime) are not assignable to each other's types. For example ZonedDateTime has all fields of CalendarDate, plus some extra fields like timeZone. So, without that that private field trick, TS won't complain if you do:

const calendarDate: CalendarDate = new ZonedDateTime(...)

My suggestion is to avoid using a private type, and solve the same issue in a different way that wouldn't require the classes to be resolved from exact same location, unnecessarily requiring @internationalized/date package be a singleton.
For example, these classes can have a normal type property serving as a discriminator:

- // @ts-ignore
- #type
+ type = 'ZonedDateTime';

It's less cryptic, embraces the TS structural type checking, rather than work around it, and so doesn't add an unnecessary requirement of the package needing to be a singleton.

[snowystinger]

Ah, I see. I had not understood the issue. Thank you for clarifying with examples.
I'll discuss this with the team and see how we want to proceed.

[snowystinger]

Chatted with the team, a little bit more would be required for this to work.
example based on string alone this version won't work, the type field is just typed as a string, so all classes match.

vs example based on typed string

We do rely on instanceof checks in some places, those will need to be addressed, and they would not work with duplicate packages either. For example

react-spectrum/packages/@internationalized/date/src/conversion.ts

Line 283 in cea5511

if (date instanceof ZonedDateTime) {

We could probably move it to a type check or 'timeZone' in date
There are probably other cases as well.

Which brings me to my last point, we are worried this will be less obvious that people should dedupe their packages. I'm not sure there is a good way for us to mark which ones are safe to have duplicates of and which are not.

[alirezamirian]

Ah, good point about the instanceof checks. Didn't notice it before. I tend to think it's worth the refactoring, especially considering how there will be multiple packages depending on it, and how package managers don't support marking a package as singleton or something that must be deduped when possible. Unlike other packages, for this package, it seems it's rather simple to make it work even if it's loaded multiple times.

[alirezamirian]

BTW, as const would also work, to narrow it down from string.

[tgelu]

Hi. I am also interested in this discussion for precisely the same reasons :).
Mind if I ask if there is any update on this or if anything changed since 2023?

[snowystinger]

No changes, it's pretty low priority for us as you can resolve to a single version via your package manager. ie yarn resolutions
This would be the recommended path. It'll have a side benefit of reducing the size of your app as well.

[tgelu]

Alright. Thanks for the answer :)
Though I would add that the complete picture, in regards to priority, should have in view developers of packages as well, where it's not feasible to use resolutions.

[kanalveli-ramachandran]

• Re-export stuff from @internationalized/date, from our component library, so that users of our library don't need to install it separately.

Have you all considered encapsulating this in the DateField exports? It feels odd to add @internationalized/date as a separate dependency for just formatting the value that's passed to the DateField.

[snowystinger]

Thanks for the feedback, we share @internationalized with some other libraries and it's react independent. We could re-export them, but that's more places for a mismatch in support, so we've opted to keep the divide as it is.

In addition, with various browsers natively supporting date manipulation in the hopefully not too far off future, some of these libraries won't be needed anymore. This gives more control to users on when they can switch and reduce their bundle size.

[kanalveli-ramachandran]

Thanks, I've added a resolution to avoid this type error for now. Please keep us posted when there's any changes to fix this.