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

Package size and number of dependencies #177

Open
armano2 opened this issue Feb 22, 2021 · 3 comments
Open

Package size and number of dependencies #177

armano2 opened this issue Feb 22, 2021 · 3 comments

Comments

@armano2
Copy link

armano2 commented Feb 22, 2021

Hello, i'm a little concerned about size of this package and number of dependencies that it requires to run,

this package has 66 dependencies and weights 175kb with all its dependencies, as a comparison yargs has 16 dependencies and weights 76kb,

most of code in this package actually come from reading and normalizing package.json and that should be a trivial task as this package uses optionally 2 fields description and version.

my suggestion is to replace normalize-package-data and read-pkg-up with find-up and simple if condition.

this change should allow to reduce number of dependencies by half and reduce size by 70%

@sindresorhus
Copy link
Owner

I guess we could remove it, but it would be a breaking change as we expose the package as a .pkg object. We would also have to document that it's not normalized and how the user needs to manually normalize it if they want to access properties.

@fregante
Copy link

I looked into the usage of read-package-up and I think there are only 3 changes:

  • version won't be normalized (if the user sets 01.02.03 they get the exact string instead of 1.2.3)
  • description won't be normalized (if the user doesn't set description, it will read the readme, but we know how bad this looks in practice)
  • pkg won't be the whole normalized package.json

The first two changes I think are not that useful. If anything, it's unexpected to get a version different from what the user set. Same for the description

The normalized pkg property honestly seems a feature that doesn't have do be here, it was added because it came "free" with the usage of read-package-up. "Normalization" is useful when accessing third-party packages, less so for one's own package in the same folder.

Here's the most recent dependency tree, for who's curious: https://npmgraph.js.org/?q=meow%4012.0.1#select=exact%3Aread-pkg-up%409.1.0

Anything past that won't be parsed correctly due to:

@fregante
Copy link

To clarify, removing it is still a breaking change, but not something a lot of people will miss.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants