Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
v7 regression: installation time is super slow
See original GitHub issueDescribe the bug (required)
We’ve recently upgraded from v6 to v7. Since that upgrade, our yarn installation awaits react-table’s @scarf/scarf dependency for a very long time (over 50s):
$ yarn
yarn install v1.22.4
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@1.2.12: The platform "linux" is incompatible with this module.
info "fsevents@1.2.12" is an optional dependency and failed compatibility check. Excluding it from installation.
info fsevents@2.1.3: The platform "linux" is incompatible with this module.
info "fsevents@2.1.3" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
[-/7] ⠠ waiting...
[-/7] ⠠ waiting...
[-/7] ⠐ waiting...
[4/7] ⠐ @scarf/scarf
[-/7] ⠐ waiting...
It finally ends after over a minute:
Done in 64.09s.
If I simply force v6 using yarn’s “resolutions”:
"resolutions": {
"react-table": "6.11.5"
},
Installation is finished in 9.82s.
Forcing v6 obviously breaks at runtime, but clearly shows the install time speed difference.
Should be noted the times above are with an up-to-date yarn.lock file and no node_modules (git clean -fdx between installation runs).
Provide an example via Codesandbox! (required) Irrelevant when discussion installation time issues, I guess?
Steps To Reproduce (required) It appears this behaviour is best seen in repositories with many dependencies. When I tested v7 on https://github.com/wixplosives/sample-monorepo, I could see a slowdown, but it wasn’t as severe.
Expected behavior (Recommended) Stay fast? 😃
Desktop (please complete the following information):
- OS: Fedora 31
- Node: v12.16.2
- npm: 6.14.4
- yarn: 1.22.4
Issue Analytics
- State:
- Created 3 years ago
- Comments:17 (6 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Thank you both for your prompt replies.
Trust me, forking is a “last resort” kind of option which I am always trying to avoid. Syncing changes to upstream is a headache and it gets even trickier with TypeScript and how
@types/<package-name>are resolved. I would rather find a solution that works for the officialreact-tablepackage.Respecting intermediate opt-out sounds like something that could resolve the issue for us. I’ll update our repo as soon as you have any fix released.
On a side note: I really appreciate the work done on
react-table, and find it super useful. Kudos for it.Sure thing! That all sounds great, and your support there is very appreciated. Will keep you posted with these updates.
You too! 😄