-
Notifications
You must be signed in to change notification settings - Fork 536
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
Webpack 5 for client mono-repo #10186
Changes from all commits
656ece1
5ae35f9
9c2eb73
bad792f
21ed32a
feaa9fc
84db76f
d34aa8b
273f3ef
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -78,17 +78,18 @@ | |
"eslint-plugin-react": "~7.28.0", | ||
"eslint-plugin-tsdoc": "~0.2.14", | ||
"eslint-plugin-unicorn": "~40.0.0", | ||
"html-webpack-plugin": "^4.5.2", | ||
"html-webpack-plugin": "^5.5.0", | ||
"jest": "^26.6.3", | ||
"jest-junit": "^10.0.0", | ||
"jest-puppeteer": "^4.3.0", | ||
"process": "^0.11.10", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Any polyfill that is transitively depended on some other way (like util, which is why we need process) is actually already being included and I don't know if that includes events and url, but it is possible. It's also quite possible some behaviors are broken, and they were just missed by our automated tests and my manual testing: the issue with process only showed up at runtime (though our automated tests did catch it as well), not build or pack time, so we could be missing things that arn't tested and still pass CI. |
||
"puppeteer": "^1.20.0", | ||
"rimraf": "^2.6.2", | ||
"ts-jest": "^26.4.4", | ||
"ts-loader": "^8.4.0", | ||
"ts-loader": "^9.3.0", | ||
"typescript": "~4.5.5", | ||
"typescript-formatter": "7.1.0", | ||
"webpack": "^4.46.0", | ||
"webpack": "^5.72.0", | ||
"webpack-cli": "^4.9.2", | ||
"webpack-dev-server": "4.0.0", | ||
"webpack-merge": "^5.8.0" | ||
|
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'd like to track down why this polyfill is needed, so I can update #9508 if needed. Do you know where it's coming from?
I think our goal should be that our packages are usable in Webpack without adding polyfills to your config. As of now the plan is to disallow node polyfills except for
events
andurl
, but that goal is really focused on our libs. Examples could continue to use polyfills directly in Webpack like you do here, but that implies that our customers will too.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.
Oh, I see now in a comment later:
I'll file an issue if you haven't already. At the very least this will need to be documented when using our packages with Webpack 5.
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 have not filed any issues about this. To me this looks like a bug in util (has an undeclared dependency), and a quality issue with whatever we use that depends on util (which would be nice for it not to depend on nodejs stuff). I'll leave how to track/address this to you.
When using webpack, I generally expect random transitive dependencies to need manual fiddling (it makes me sad this is something I have accepted), but I suppose trying to get this fixed could help our consumers and may be worth 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.
I added #10225.