-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[docs] Limit date-fns
package to v2 in codesandbox
#11463
Conversation
Deploy preview: https://deploy-preview-11463--material-ui-x.netlify.app/ |
@@ -59,7 +64,6 @@ ponyfillGlobal.muiDocConfig = { | |||
'@mui/x-date-pickers-pro': getMuiPackageVersion('x-date-pickers-pro', muiCommitRef), | |||
'@mui/x-charts': getMuiPackageVersion('x-charts', muiCommitRef), | |||
'@mui/x-tree-view': getMuiPackageVersion('x-tree-view', muiCommitRef), | |||
'date-fns': 'latest', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Defining the version did not work, because this would override it:
WDYT @flaviendelangle, does the proposal make sense or shall we refactor the code in monorepo
?
But in that case, we'd be blocked for the moment, because we currently can't bump monorepo
. 🙈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How long do we think we will be blocked from bumping the monorepo?
Having latest
hardcoded is really not a good pattern 😬
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How long do we think we will be blocked from bumping the monorepo?
Given the complexity of #11303 I'd bet that it is not happening this year. 😃
So, at least 2+ weeks of a few broken demos in codesandbox.
Having
latest
hardcoded is really not a good pattern 😬
I don't disagree. It's error-prone, like we see now. 🙈
But I'd say that in such case, all of it should be controlled on the consuming side.
Now we have a bunch of logic in monorepo, some of it overrides whatever we specify here... 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would be totally fine if you took the current commit of the monorepo on your repo and just did the date-fns fix
That's not clean, but this is a very bad regression on our doc 😬
But I'd say that in such case, all of it should be controlled on the consuming side.
Yes you're right
latest
is bad AND having to go to the monorepo to fix it is bad...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@flaviendelangle WDYT about the updated solution with fixes originating from @mui/monorepo
? 🤔
@@ -21,4 +21,5 @@ module.exports = { | |||
'**/build/**', | |||
'docs/.next/**', | |||
], | |||
spec: ['packages/**/*.test.{js,ts,tsx}', 'docs/src/modules/**/*.test.{js,ts,tsx}'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change prevents pnpm tc
from working. Restoring this in #14852.
Noticed that our codesandboxes using
date-fns
will no longer work after the v3 release.Discovered while investigating #11454.
Uses changes in mui/material-ui#40257.