Open Source Insights | Hacker News Reader

Open Source Insights

deps.dev

55 pointshasheddan14 comments

To the Googler who created this I say congrats on the promotion.

To the rest of the HN crowd, I would like to propose a game. You suggest how many months it will take until this will end up here:

https://gcemetery.co/

The one closest wins.

Here goes my bet : 24 months

See you all in 2 years or sooner...

22 months

Title could be better. add "Dependency Graphs".

"Dependency Graphs for Open Source packages" or something

Similar: https://libraries.io/

Funnily enough for openfaas/faas - only the Google product showed dependencies. Both different tools also showed different "dependents"

If the exercise is to capture / mediate GPL2/3 dependencies, then having results missing kind of defeats the purpose.

Cool. Ironically, not open-source. +1 on wanting Ruby.

Pretty nice site the only issue I have is that the Crates.io part does not differentiate between development dependencies and normal dependencies.

looks like a lot of useful information however it's unfortunate they didn't add rubygems analytics and project dependencies as a whole report or api support.

TIL you can just look up the personal emails of the entire React core team just by visiting this page now

https://deps.dev/npm/react

one of the many poor decisions of npm: being completely blase about privacy.

Others would call that being transparent and reachable.

I mean, depends on who puts it there? If the contributors list their emails knowingly for that purpose, that's one thing. If a tool leaks your NPM account email, which you have no control over, that's not exactly transparency.

You can see the Collaborator's NPM profile, where _they_ can set handles to contact them at. You can also get to their GitHub profile where they also can set handles to contact them at. If the tool made it easier to see those, then great.

These emails don't appear to be directly listed on NPM's website. Or correlated with Github/NPM profile. My guess is they're surfacing the email associated with that user's NPM account? Which is not otherwise obviously listed. And the only way you could control it is by also affecting who is an owner of the NPM project itself.

If that is the case, then contributor's emails are being 'leaked' without their say-so or probably knowledge, and without any particular way of managing it. Meanwhile they've already listed perfectly good ways of being 'reachable'.

> If that is the case, then contributor's emails are being 'leaked' without their say-so or probably knowledge

When you login into the NPM CLI it printed in all caps that the given email address will be public.

I don't like this either about NPM, but it's not like they are leaking in, they are upfront about it and warn you that the registered email address will be accessible to anyone in the package metadata.

Yes, that is totally true. That's kinda what I was going for putting 'leaked' in quotes. It's not really leaked because the data is technically public. You can of course scrape it from say: https://registry.npmjs.org/react

However, it's been made significantly more accessible in a tool like this. NPM doesn't list it prominently in their UI anywhere (I believe).

So the 'leak' is up-publicizing data outside of the control of the owner, and when other, intentional (and likely better) alternatives exist.

That seems to be straight from the NPM feed: https://registry.npmjs.org/react/17.0.2

So at least it's on NPM and not this new thing.

Reply on news.ycombinator.com