-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
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
Dependency of @types/react-loadable
causes type conflict issues in 2.0.0-beta.7/8
#5772
Comments
@types/react-loadable
causes type conflict issues starting in 2.0.0-beta.7@types/react-loadable
causes type conflict issues in 2.0.0-beta.7/8
Mmmm, I do remember seeing these errors somewhere, but now I can't reproduce elsewhere.
I think that's sufficient to conclude that at least this is not a widespread issue. Not to dismiss your issue as irrelevant or unimportant, but I think we either need to look into the setup of
Per documentation of this fork:
Also, we still import the modules as
I'm actually unsure why |
I actually did try adding @types/webpack to my resolutions as you suggested so when you I saw your edit I figured maybe I misremembered and it did work. I went ahead and tried again, and now I see again why it didn't work. For whatever reason doing so causes a JavaScript Heap Out Of Memory issue. I ran Then I tried bumping the max old space to 5120 and that actually seems to have it work consistently. What in tarnation sake could be causing it to need >= 4GB && < 5 GB RAM just to run is truly beyond me. It sure as heck can't be my hardware specs (64 GB RAM @ 3200 MHz, Ryzen 3900X). What's also notable is that this extreme RAM requirement is only for typedoc, because once the webpack server is running the Node application is consuming about 920 MB of RAM on my system which is a pretty reasonable amount considering the V8 engine is likely to realize there's so much available anyway that it might as well. (My browser commonly consumes 1-1.5 GB RAM as well, even with just a few tabs open) For now what I think I'll do is update to beta 8, add the resolutions field and make this change in our scripts but I'd really like to help in any way I can with getting to the bottom of why the typedoc plugin consumes so much RAM when tasked with the amount of projects that we task it with. - "docusaurus": "docusaurus",
- "start": "docusaurus start",
- "build": "docusaurus build",
+ "docusaurus": "cross-env NODE_OPTIONS=\"--max-old-space-size=5120\"",
+ "start": "cross-env NODE_OPTIONS=\"--max-old-space-size=5120\" docusaurus start",
+ "build": "cross-env NODE_OPTIONS=\"--max-old-space-size=5120\" docusaurus build", |
That I have no idea. I suspect it's that typedoc goes into the entire |
react-loadable is not maintained anymore and our fork just made some fixes for webpack 5 afaik. We could basically just replace its typedefs with I'd like to replace it someday but considering React.lazy SSR + Suspense support is coming in React 18, I'd rather not migrate to loadable-components now. |
@slorber Do you by any chance know why react-loadable still works in WP5 without any changes? Is our usage not touching any WP4 API? |
It works because there were no Webpack breaking changes affecting it, by luck. Apparently my fork only removed the annoying deprecation warning: I'm trying to get a docusaurus-core org to move all our forks there and make things more explicit |
Yeah, I'm asking because of this remark |
please test the canary release |
@slorber I just tried out Canary ( |
Great, thanks 😜
Le ven. 29 oct. 2021 à 22:06, Jeroen Claassens ***@***.***> a
écrit :
… @slorber <https://github.com/slorber> I just tried out Canary (0.0.0-4137)
and can confirm that this issue is fixed. I no longer need the cross-env
NODE_OPTIONS=\"--max-old-space-size=5120\" I mentioned in my previous
comment. Thanks for the awesome work!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5772 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFW6PWONOYCE4WQ3KGY5LTUJMEDXANCNFSM5GRPWZ2A>
.
|
🐛 Bug Report
Prerequisites
npm run clear
oryarn clear
command.rm -rf node_modules yarn.lock package-lock.json
and re-installing packages.I have tried creating a repro with https://new.docusaurus.io( N.A. because those samples are using JavaScript and this is TypeScript issue. There is a repository linked below)Description
In the PR #5601 a change was made to ensure
@types
packages are in the dependencies instead of the dev-dependencies. This however introduced a regression issue in@docusaurus/module-type-aliases
through@types/react-loadable
. Specifically, those types still depend on@types/webpack ^4
which conflicts with Docusaurus using Webpack 5 as of #4089.I have already added
"skipLibCheck": true
to my/tsconfig.json
but that is completely to no avail. I don't know how Docusaurus reads the tsconfig exactly but it seems to disregard at least that property.My suggestion for the fix is one of:
@types/react-loadable
dependency. You guys have your own@docusaurus/react-loadable
fork. I'm not sure why@docusaurus/module-type-aliases
is even depending on the types? Why not add the necessary types that you do need to your fork so you have no dependency at all anymore on the original work?@types/react-loadable
back to dev-dependencies@types/react-loadable
starts using Webpack v5 by contributing that to DefinitelyTypedHere are some console outputs and yarn lockfile dumps:
Have you read the Contributing Guidelines on issues?
Yes 😄!
Steps to reproduce
Use https://new.docusaurus.io to create a CodeSandbox reproducible demo of the bug., N.A. because those samples are using JavaScript and this is TypeScript issue. I have a branch on my repo, however.git clone --recurse-submodules -j8 https://github.com/sapphiredev/website.git && git submodule update --init --recursive
feat/update-to-docusaurus-beta-8
yarn install
to setup the dependency tree (note: due to submodules being in the yarn workspace this takes a bit)yarn start
.Expected behavior
Everything builds fine without type errors. I have no breaking changes to cover between betas 6 and 8.
Actual behavior
When running
docusaurus start
with 2.0.0-beta.8 I get all of these type errors from node_modules directories:click me to expand large code block
Your environment
Reproducible demo
Use https://new.docusaurus.io to create a CodeSandbox reproducible demo of the bug.N.A., see reason above.git clone --recurse-submodules -j8 https://github.com/sapphiredev/website.git && git submodule update --init --recursive
feat/update-to-docusaurus-beta-8
yarn install
to setup the dependency tree (note: due to submodules being in the yarn workspace this takes a bit)yarn start
.The text was updated successfully, but these errors were encountered: