Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # 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.

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

No branches or pull requests

3 participants