Skip to content
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

Question: is yarn size fair comparison with npm? #987

Closed
lovell opened this issue Jul 23, 2022 · 7 comments · Fixed by #1021
Closed

Question: is yarn size fair comparison with npm? #987

lovell opened this issue Jul 23, 2022 · 7 comments · Fixed by #1021
Labels
question Further information is requested

Comments

@lovell
Copy link

lovell commented Jul 23, 2022

Hi Steven, thanks as always for this useful tool.

I noticed an increase in the reported installation size of the sharp package from 20.2MB to 24.3MB between v0.30.4 and v0.30.5 - see https://packagephobia.com/result?p=sharp

This didn't seem quite right to me, so I had a quick look at the commits and noticed you switched from npm to yarn via #959 around the same time.

It looks like the increase in reported disk usage is due to now including yarn's extra cache data in the calculations. Perhaps this should be removed to ensure a fair comparison with the previous use of npm?

Here's a worked example:

$ docker run -it --rm node:18-alpine /bin/sh
apk add git
yarn set version 2.4.3
cd /tmp
yarn init
yarn add sharp

du -sh .yarn
24.0M	.yarn

yarn cache clean

du -sh .yarn
21.8M	.yarn
@styfle
Copy link
Owner

styfle commented Jul 26, 2022

Hey, thanks!

The .yarn directory isn’t measured, just node_modules

@lovell
Copy link
Author

lovell commented Jul 26, 2022

Ah yes, thank you, I hadn't spotted the use of YARN_NODE_LINKER to create this.

YARN_NODE_LINKER: 'node-modules',

What I believe is happening is that yarn now always copies the latest version of node-gyp into the local tree (rather than treat it as a global dependency like npm) when it sees any package with a binding.gyp file, regardless of prebuilt binary provision.

This means all native dependencies will appear to be ~4MB larger with yarn compared with npm. I'm unsure what, if anything, should be done about this.

@styfle
Copy link
Owner

styfle commented Jul 26, 2022

Also note Yarn 3 is used now, not Yarn 2

But maybe I should switch to Yarn 1 which seems to follow npm behavior a little more closely. Trying it out here:

@styfle styfle added the question Further information is requested label Jul 26, 2022
@styfle
Copy link
Owner

styfle commented Aug 3, 2022

Hmm, something does seem wrong because uploading package.json shows the dependencies should be about 2MB https://packagephobia.com/[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected]

I'l try switching to Yarn 1 or to pnpm and see if that is more accurate. I would like to continue using npm but they no longer support programatic access so I was stuck on npm 6.

@styfle styfle changed the title Question: should yarn cache be cleared before measuring disk usage to ensure fair comparison with npm? Question: is yarn size fair comparison with npm? Aug 7, 2022
@styfle
Copy link
Owner

styfle commented Aug 7, 2022

Yarn 1 (left) installs fewer dependencies than Yarn 3 (right) 🤔

{
  "private": true,
  "dependencies": {
    "sharp": "^0.30.7"
  }
}

image

I tried switching to Yarn 1 in #988 but it fails to install next, likely because yarn 1 doesn't respect the libc field and the Serverless Function runs out of space.

@styfle
Copy link
Owner

styfle commented Nov 12, 2023

I finally had to upgrade yarn and decided to switch back to npm.

Take a look again and let me know if there are any problems with the measurement for sharp now, thanks!

@lovell
Copy link
Author

lovell commented Nov 12, 2023

https://packagephobia.com/result?p=sharp looks good, thank you Steven.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
2 participants