search

mui / mui-x

MUI X: Build complex and data-rich applications using a growing list of advanced React components, like the Data Grid, Date and Time Pickers, Charts, and more!
https://mui.com/x/
4.54k stars 1.32k forks source link

[pickers] Can't use multiple version of the packages at the same time #4569

Closed JonathanGuo closed 2 years ago

JonathanGuo commented 2 years ago

Duplicates

Latest version

Current behavior 😯

DesktopDateRangePicker's useUtils has null value when use context with MuiPickersAdapterContext. I've gone through the process and ensured the LocalizationProvider has been initialised correctly.

Context initialised:

image

Value is null:

image

Hence I have the errors:

image

Expected behavior 🤔

I've tested with @mui/x-date-pickers-pro@5.0.0-alpha.0. The Localization initialises without any issue.

Steps to reproduce 🕹

Steps:

  1. Upgrade to @mui/x-date-pickers-pro@5.0.0-alpha.1
  2. Add <LocalizationProvider dateAdapter={AdapterDateFns} />
  3. Add underneath
  4. Reload the app

Context 🔦

I am upgrading React to 18, Mui and Mui X Pro to the latest version. After upgrading the @mui/x-date-pickers-pro to 5.0.0-alpha.1, the error 'MUI: Can not find utils in context. It looks like you forgot to wrap your component in LocalizationProvider, or pass dateAdapter prop directly.' thrown out when using the DesktopDateRangePicker component.

Your environment 🌎

`npx @mui/envinfo` ``` System: OS: macOS 12.2.1 CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz Memory: 28.93 MB / 16.00 GB Shell: 5.8 - /bin/zsh Binaries: Node: 16.13.0 - /usr/local/bin/node Yarn: 1.22.10 - /usr/local/bin/yarn npm: 8.1.0 - /usr/local/bin/npm Managers: Cargo: 1.58.0 - ~/.cargo/bin/cargo CocoaPods: 1.8.4 - /usr/local/bin/pod Composer: 2.0.8 - /usr/local/bin/composer Homebrew: 3.4.5 - /usr/local/bin/brew pip2: 19.3.1 - /usr/local/bin/pip2 pip3: 20.3.1 - /usr/local/bin/pip3 RubyGems: 3.0.3.1 - /usr/bin/gem Utilities: Make: 3.81 - /usr/bin/make GCC: 13.1.6 - /usr/bin/gcc Git: 2.29.2 - /usr/local/bin/git Clang: 13.1.6 - /usr/bin/clang Servers: Apache: 2.4.51 - /usr/sbin/apachectl Virtualization: Docker: 20.10.13 - /usr/local/bin/docker VirtualBox: 5.2.20 - /usr/local/bin/vboxmanage SDKs: iOS SDK: Platforms: DriverKit 21.4, iOS 15.4, macOS 12.3, tvOS 15.4, watchOS 8.5 Android SDK: API Levels: 23, 25, 26, 27, 28, 29 Build Tools: 23.0.1, 26.0.3, 27.0.3, 28.0.1, 28.0.3 System Images: android-23 | Google APIs Intel x86 Atom_64, android-25 | Google APIs Intel x86 Atom_64, android-26 | Google APIs Intel x86 Atom, android-26 | Google APIs Intel x86 Atom_64, android-26 | Google Play Intel x86 Atom IDEs: Android Studio: 4.0 AI-193.6911.18.40.6514223 Nano: 2.0.6 - /usr/bin/nano PhpStorm: 2021.3.3 VSCode: 1.66.2 - /usr/local/bin/code Vim: 8.2 - /usr/bin/vim Xcode: 13.3.1/13E500a - /usr/bin/xcodebuild Languages: Bash: 3.2.57 - /bin/bash Java: 1.8.0_171 - /usr/bin/javac Perl: 5.30.3 - /usr/bin/perl PHP: 8.1.4 - /usr/local/bin/php Python: 2.7.17 - /usr/local/bin/python Python3: 3.9.1 - /usr/local/bin/python3 Ruby: 2.6.8 - /usr/bin/ruby Rust: 1.58.1 - /Users/jonathanguo/.cargo/bin/rustc Databases: PostgreSQL: 14.2 - /usr/local/bin/postgres SQLite: 3.36.0 - /usr/bin/sqlite3 Browsers: Chrome: 100.0.4896.127 Firefox: 97.0.2 Safari: 15.3 ```

Order ID 💳 (optional)

34248

JonathanGuo commented 2 years ago

TBH I can't reproduce the issue in CodeSandbox. I've re-installed all the dependencies without cache and tested with minimum code but the issue still exists at my local.

cherniavskii commented 2 years ago

@JonathanGuo sounds very similar to https://github.com/mui/mui-x/issues/4537#issuecomment-1102840520. Can you check versions of @mui/x-date-pickers and @mui/x-date-pickers-pro?

JonathanGuo commented 2 years ago

@cherniavskii The @mui/x-date-pickers version is 5.0.0-alpha.0, and the @mui/x-date-pickers-pro is 5.0.0-alpha.1.

Interestingly, the installed node_modules/@mui/x-date-pickers version is 5.0.0-alpha.0 when I have the following packages with dependencies:

├─┬ @mui/lab@5.0.0-alpha.78
│ └── @mui/x-date-pickers@5.0.0-alpha.0
└─┬ @mui/x-date-pickers-pro@5.0.0-alpha.1
  └── @mui/x-date-pickers@5.0.0-alpha.1

The issue has been fixed after I force installed the @mui/x-date-pickers@5.0.0-alpha.1.

I think to resolve the issue it just needs to update the @mui/lab's dependency versions.

cherniavskii commented 2 years ago

Thanks @JonathanGuo That's an interesting problem.

So both @mui/lab and @mui/x-date-pickers-pro have @mui/x-date-pickers as dependency. And we can have 2 scenarios here:

  1. @mui/lab and @mui/x-date-pickers-pro depend on the same version of @mui/x-date-pickers. Best case scenario. @mui/x-date-pickers is installed once (depends on package manager?) and there's no version mismatch.

  2. @mui/lab and @mui/x-date-pickers-pro depend on the different versions of @mui/x-date-pickers. This one is tricky. When importing pickers from both @mui/x-date-pickers-pro and @mui/x-date-pickers, there's a high chance their versions won't match. Here's a codesandbox: https://codesandbox.io/s/basicdatepicker-material-demo-forked-mfg6bc?file=/package.json that results with error:

    MUI: Can not find utils in context. It looks like you forgot to wrap your component in LocalizationProvider, or pass dateAdapter prop directly.

    While we can (and should) always update @mui/x-date-pickers version in @mui/lab, this won't solve a problem where users only update @mui/x-date-pickers-pro.

Currently, we mention that:

Components of the Community Plan such as <DatePicker /> can be imported from both @mui/x-date-pickers-pro and @mui/x-date-pickers. Only date adapters such as AdapterDayjs can only be imported from @mui/x-date-pickers/[adapterName] https://mui.com/x/react-date-pickers/migration-lab/#2-run-the-code-mod

Option 0: I think we should advise our users to avoid imports from @mui/x-date-pickers when using @mui/x-date-pickers-pro. Here is a working demo with @mui/lab installed as well: https://codesandbox.io/s/basicdaterangepicker-material-demo-forked-hw6erc?file=/demo.tsx We should also re-export adapters in @mui/x-date-pickers-pro to be able to get rid of @mui/x-date-pickers imports completely.

Option A: Another option is to remove pickers from @mui/lab completely. But I'm not sure if we should do this right now.

JonathanGuo commented 2 years ago

@cherniavskii Thanks for the CSB samples and the very detailed explanation. I think a documentation update would be truly helpful for @mui/x-date-pickers-pro users.

oliviertassinari commented 2 years ago

The root cause seems to be that @mui/x-date-pickers-pro has a dependency on @mui/x-date-pickers but @mui/x-date-pickers has a singleton: the React context. I wonder if we don't have the same problem with @mui/x-data-grid to a lesser level.

Option 0:

Could maybe work, is it what we recommend with the data grid?

Option A:

I don't think that it would permanently solve the problem, developers using both pro and community could still get dependency duplication when updating even without the lab.

Option B: @alexfauquette Proposed to duplicate the adapters such that they are directly available in the pro package and so we ensure version synchronization. From my perspective, it would still make it so that developers can't mix the imports between packages, hence not really solve the problem.

Option C: Another option is to make @mui/x-date-pickers a peer dependency in @mui/x-date-pickers-pro, to force developers to install both avoiding duplications. A number of projects are doing this.

It's to be noted that all developers should likely deduplicate their dependencies, e.g. having a step like this in their CI:

https://github.com/mui/mui-x/blob/2150684df26a381ba12410fa9684aa0f89ae0ec4/.circleci/config.yml#L120-L122

flaviendelangle commented 2 years ago

We should also re-export adapters in @mui/x-date-pickers-pro to be able to get rid of @mui/x-date-pickers imports completely.

Option B: @alexfauquette Proposed to duplicate the adapters such that they are directly available in the pro packag

I think we can have similar problems on other internals (like WrapperVariantContext) But this would be worth testing.

I wonder if we don't have the same problem with @mui/x-data-grid to a lesser level.

If you have 2 versions of the grid, yes probably.

cherniavskii commented 2 years ago

Similar case - using pickers from both @mui/lab and @mui/x-date-pickers: https://github.com/mui/mui-x/issues/4583

mauro-ni commented 2 years ago

I solved importing LocalizationProvider from @mui/x-date-pickers-pro (Option 0)

Before

import LocalizationProvider from '@mui/x-date-pickers/LocalizationProvider';

After

import { LocalizationProvider } from "@mui/x-date-pickers-pro";
cherniavskii commented 2 years ago

Option C: Another option is to make @mui/x-date-pickers a peer dependency in @mui/x-date-pickers-pro, to force developers to install both avoiding duplications. A number of projects are doing this.

I like this one, it should work

joserodolfofreitas commented 2 years ago

In a first overview, I think it's worth trying Option 0.

Option C seems to be the only definitive solution to the initial problem (perhaps not the most elegant in terms of DX). But I'm wondering, as peer dependencies, would we not potentially have problems with mismatched versions as well?

It's to be noted that all developers should likely deduplicate their dependencies, e.g. having a step like this in their CI:

That sounds like a good idea as a seed for an educational article.

joserodolfofreitas commented 2 years ago

Similar case - using pickers from both @mui/lab and @mui/x-date-pickers: #4583

Also, even though removing the dependency from @mui/lab doesn't really solve the problem, it will help mitigate the risk that our users will face this issue. Eliminating most of the friction. Perhaps we should re-evaluate if it's worth not making a breaking change here. Considering that, I'm in favor to remove the dependency from @mui/lab.

flaviendelangle commented 2 years ago

@mnajdova

laurisvan commented 2 years ago

Note: it appears that indeed npm dedupe can solve the problem, or simply just having @mui/x-date-pickers-pro and no @mui/x-date-pickers dependency at all. Both are a bit hacky ways to fix the problem, but at least they help us to cope with the problem until it is fixed.

flaviendelangle commented 2 years ago

You have both @mui/lab and @mui/x-date-pickers-pro with various versions of @mui/x-date-pickers.

@cherniavskii couldn't we fix it by accepter a range version on the lab ? 

-    "@mui/x-date-pickers": "5.0.0-alpha.0",
+    "@mui/x-date-pickers": "^5.0.0-alpha.0",
cherniavskii commented 2 years ago

@flaviendelangle I don't think so, because it won't guarantee package deduplication. But it is still a valid question - should we support range version of @mui/x-date-pickers in @mui/lab? From maintenance perspective - it's a one-time change that will allow @mui/lab users to pull the latest version of pickers. I think we should go for it.

flaviendelangle commented 2 years ago

It may not cover every case, but I think it will lower a lot the amount of people with package duplication. So it could be an interesting quick fix

A downside is that it lower the need to migrate to our package since the lab will also get the bug fixes But since we added runtime warning when using the components on the lab, I guess people will migrate anyway if they updated to a version of the lab that just re-export our package.

cherniavskii commented 2 years ago

Let's discuss it here: https://github.com/mui/material-ui/pull/32494

oliviertassinari commented 2 years ago

Regarding the next step, I believe it's either:

Compare

https://github.com/mui/mui-x/blob/f1a4e8bb095b3e40ba0b84bc872b1a60f74305e5/packages/grid/x-data-grid/src/hooks/utils/useGridApiContext.ts#L12-L18

and

https://github.com/mui/mui-x/blob/f1a4e8bb095b3e40ba0b84bc872b1a60f74305e5/packages/x-date-pickers/src/internals/hooks/useUtils.ts#L10-L12

I think that the message of the data grid is already clearer but could be improved too.

Since the data grid is already on Option 0, maybe it would make sense to continue in this direction? Unclear

cherniavskii commented 2 years ago

+1 for option C

flaviendelangle commented 2 years ago

We did not have any feedback since I removed the pickers from the lab. I propose to just improve the error message like on the data grid packages and close it.

RicardoRien commented 1 year ago

As @JonathanGuo wrote, the solution is downgrade the packages. This works for me: yarn add @mui/x-date-pickers@5.0.20 and if you are using a DateCalendar in MUI version 5 it's called CalendarPicker import { CalendarPicker } from "@mui/x-date-pickers";