-
-
Notifications
You must be signed in to change notification settings - Fork 32.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] Avoid popper.js npm warning #20433
[core] Avoid popper.js npm warning #20433
Conversation
10c6b08
to
54ecbb0
Compare
54ecbb0
to
35682fd
Compare
Details of bundle changes.Comparing: 52b80a0...e800daf Details of page changes
|
I thought about a solution, I published |
I would prefer this solution. That preserves the import identifier which might be relevant for aliases. |
@FezVrasta Awesome, this sounds even better, updating. |
Something is off with the current solution: npm
yarn
It resolves to:
What about this diff? diff --git a/packages/material-ui/package.json b/packages/material-ui/package.json
index 2d5560541..38d4d3fbc 100644
--- a/packages/material-ui/package.json
+++ b/packages/material-ui/package.json
@@ -56,7 +56,7 @@
"@types/react-transition-group": "^4.2.0",
"clsx": "^1.0.4",
"hoist-non-react-statics": "^3.3.2",
- "popper.js": "^1.16.1-lts",
+ "popper.js": "1.16.1-lts",
"prop-types": "^15.7.2",
"react-is": "^16.8.0",
"react-transition-group": "^4.4.0" cc @dandv |
@oliviertassinari that should work according to https://semver.npmjs.com/ I think the only way for the caret to not pick it up is if it was released as |
A second iteration mui#20433 (comment).
FWIW this is an unfortunate diversion from semver. Using the |
I propose that we temporarily fork popper.js to avoid this warning. The fork is hosted at https://github.com/mui-org/popper-core.
I think that popper.js was right to make this deprecation, However, the concern for us is different: users have no leverage, we force it on them.
Solving the npm warnings is hard enough, Material-UI doesn't need to force this one on users. I think that we should educate users (give a feedback loop) that npm warnings are not to be ignored, they can harm. Displaying them a warning they can't make actionable doesn't foster this virtuous cycle where developers pay more attention to the npm warnings.
We should revisit this in v5.
Related to #19358.