-
-
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
[core] Bump monorepo #14141
[core] Bump monorepo #14141
Conversation
Deploy preview: https://deploy-preview-14141--material-ui-x.netlify.app/ Updated pages: |
I updated the PR to
|
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've removed the introduction of type exporting by removing the internal type usage in documentation page component.
@Janpot Is there anything else we are waiting for this PR to be ready? |
I haven't addressed this yet. But I can also look into it separately, doesn't necessarily have to be a blocker. |
It could be due to a misconfigured |
It's likely that the X version of this rule is overwriting a default somewhere. It's quite complicated to extend this rule. Core wasn't even doing it correctly within its repo. It's not a huge problem, I saw that X has made a very detailed setup, I'd like to bring some of this infra to core. |
@LukasTy
In general I'd recommend against deeper imports, we're having this convention, It'll be easier to manage our linting rules and build tools if we adhere to it and not have to declare exceptions every time. I'd keep it for when there's a real good reason to do so. Found an issue where |
Nice, thanks @Janpot, looks great! 👏 💙 |
The TS error Has been fixed in mui/material-ui#43199 just merged so bumping could solve some errors. But most of them are from missing type for But I'm not sure if it should be fixed on the core repository, or if tsconfig should point to the monorepo on X side |
Without a too-deep investigation, I think we should add this path to the |
I tried |
I don't think tsconfig paths apply to anything else than project files, so it's in code that we will need to reference this |
@@ -1,7 +1,8 @@ | |||
import * as React from 'react'; | |||
import { PieChart } from '@mui/x-charts/PieChart'; | |||
|
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.
Can't remove this newline for some reason. But didn't take the time to look into it.
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 behavior is known and we tend to ignore it. 🙈
P.S. I take it that adding type
after import
doesn't change anything? 🤔
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.
It signals compilers that this import is not usable as a javascript value. Can be important depending on the context this is compiled in.
Should be ready to review. Have a small comment that we could still resolve. I'm a bit allergic to |
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.
LGTM!
Thank you for the effort once again. 🙏
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.
Thanks for all the fixes.
Closes #14084.
Just realized I made a few breaking changes in the eslint setup.
@LukasTy Just have two errors on nested imports from the pickers package. How would you prefer to deal with those? just Ignore? Disable in config? Or move the export up one level?