Closed favna closed 3 years ago
Mmmm, I do remember seeing these errors somewhere, but now I can't reproduce elsewhere. skipLibCheck
won't work because it only gives up on checking transitive declarations. Observations:
yarn tsc
in our own website succeeded (and our website has covered a lot of possible usage cases)yarn tsc
/ yarn start
on two of my websites using Docusaurus (one with quite some customizations) succeededI 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 docusaurus-plugin-typedoc
or find a patching solution on your side, e.g. setting "resolutions": {"@types/webpack": "^5.28.0"}
since you are using yarn
- Remove the entire
@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?
Per documentation of this fork:
IMPORTANT: this is a minimalistic fork to solve the
componentWillMount
warning for the facebook/docusaurus project.We don't plan to maintain this problem, just get rid of the warning.
Also, we still import the modules as 'react-loadable'
through Webpack alias, so we do need type definitions on the @types/react-loadable
side.
- Ensure
@types/react-loadable
starts using Webpack v5 by contributing that to DefinitelyTyped
I'm actually unsure why @types/react-loadable
depends on @types/webpack@^4
when there's also a @types/webpack@5
available, perhaps a DT publishing problem. I'll consult what's the best solution to this
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 docusaurus start
also with --max-old-space-size=4096
but to no avail. I then tried --inspect ----max-old-space-size=4096
which suddenly worked, however as I was in the debugger at the same time I did get a breakpoint where Node detected a possible memory leak, which was in TypeScript code. This was while as far as Docusaurus was concerned it was still running typedoc things.
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 webpack
to map out the type information which brings in a lot of overhead, compared to the much smaller @types/webpack
.
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 any
and get rid once for all of Webpack 4 typings, that wouldn't be so harmful.
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: https://github.com/slorber/react-loadable/commits/master
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 (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\"
, nor the resolution for @types/webpack
(which doesn't get installed at all anymore now, as it should be). Thanks for the awesome work!
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 https://github.com/facebook/docusaurus/issues/5772#issuecomment-955017386, 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 https://github.com/facebook/docusaurus/pull/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 https://github.com/facebook/docusaurus/pull/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
``` Error: node_modules/@types/webpack/index.d.ts:32:3 - error TS2305: Module '"tapable"' has no exported member 'Tapable'. 32 Tapable, ~~~~~~~ Error: node_modules/@types/webpack/index.d.ts:1081:23 - error TS2707: Generic type 'SyncWaterfallHookYour 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
.