table: v7 regression: installation time is super slow

Describe 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

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 17 (6 by maintainers)

Most upvoted comments

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 official react-table package.

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.