Lots of "unknown"s

[zachlysobey]

This tool looks pretty cool, but as of now, it seems like most of my dependencies come up as unknown for the project I tried it on. This includes popular libraries like "mustache", "winston", "express", "socket.io", "request", and "passport". If this is expected and being worked on, maybe it'd be useful to add a section to the README. "why is my dependency 'unknown'" or something like that?

[antonk52]

Hi and thank you for the issue!

In my experience I only got unknown for packages when the package is only available under a different registry. For example a company can have its own registry to avoid publishing packages to the public https://registry.npmjs.org.

I've just inited a new project with the dependencies you mentioned, however this tool works as expected, you can see package.json below

package.json

{
  "name": "test-why",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "express": "^4.17.1",
    "mustache": "^3.2.1",
    "passport": "^0.4.1",
    "request": "^2.88.0",
    "socket.io": "^2.3.0",
    "winston": "^3.2.1"
  }
}

I can also see that packagephobia reports the size as expected for these packages.

express
mustache
passport
request
socket.io
winston

Can you provide a portion of your package.json with these dependencies for me to reproduce the issue?

[zachlysobey]

In this case, these things are going through a private npm registry, though, of course, those are public packages. I'm a bit reluctant to share any more than just package names at this point (being extra careful to not break any of my company's rules) but I suspect its something to do with our registry setup (?) and I think your reproduction looks fairly close in versions to (at least some of) mine.

I'm eager to try this out on my own personal stuff though. I'll let you know if I run into any issues.

[ahalf-yuan]

Hi, thanks for your tool, it looks very cool. But how do I optimize the dependencies when I get the "Publish Size" and "Install Size" ?

[antonk52]

Hi, @yuanyazhen, thanks for the question, it seems unrelated to this issue, but I will try my best to answer.

If you plan to optimize your dependency size I would suggest approaching it like so

1. See if all your dependencies are up to date by running npm outdated in your project. If there are outdated packages consider updating. Besides bug fixes and new features that size of the package could be addressed in a newer version. You can see the size of the package in different versions with packagephobia.
2. See what are the largest packages you depend on(typically the easy hanging fruit) with why-npm-i-so-long, see what they contain of and consider contributing to reduce their size.
3. If there are some large dependencies from which you use very little of their functionality, consider searching for a package that does exactly that what you need.
4. Consider switching some dependencies to their smaller alternatives. Some common examples could be react -> preact, chalk -> kleur, express -> polka and so on. I have not seen a curated list of lighter alternatives to popular packages. If you find one make sure to note it in a comment for future readers.

[ivshalin]

I found that dependency with ~ could get 'unknown' as a result.
I tried to check "re-reselect": "~1.0.0" and got 'unknown', but "re-reselect": "1.0.0" works fine.

[antonk52]

@ivshalin there was error for package versions starting from ~<>=^, I've published a new version @1.0.2 which includes the fix. Please update or run with npx why-npm-i-so-long and you should be able to see the package size. Thank you for message 🙂

[ivshalin]

@antonk52 Thank you for the fix! It works :)

[simllll]

Any way to get this also working for private npm packages? right now i only get errors like:
@hokify/organization-data - api failed

@hokify/organization-service - api failed

[antonk52]

@simllll hi

Currently this package uses public api from package phobia. Since package phobia is open source you could potentially host it internally and give it permission to access your internal registry / private package. Then we could allow users to provide API endpoint to call that would be able to resolve private packages.

[simllll]

Ah thanks for the quick response, right now this is a bit too much effort for debugging and playing around with it. But thanks for the insights :-)