Given each dependency specification, it looks like the code fetches the oldest possible version of each package. For example, [email protected] specifies apache-md5 ^1.0.6. Since the latest version of apache-md5 is 1.1.2, that's the version that npm would fetch. However, the generated graph shows [email protected].

I'll suggest that the graph should use the version that npm would fetch (I don't even know if there's a way to tell npm "fetch the oldest possible version of each dependency").

I noticed that a package still appears as 2.0.0 even though 2.0.1 was published.

Example: https://npm.broofa.com/[email protected]

webext-dynamic-content-scripts depends on "webext-additional-permissions": "^2.0.0", which npm install resolves to [email protected] today, but npmgraph still shows 2.0.0

Semver details: https://flaviocopes.com/npm-semantic-versioning/

I published the 2.0.1 version 10 minutes ago so I'm not sure if this is due to cache.

'Took a quick look at setting this up in Vercel. Unfortunately they don't allow organization-owned repos on personal accounts so I don't think we can do this on a free plan. But they do support opensource projects.

If you could take care of setting that up, that would be helpful.

Since we're going this route, It probably makes sense to have building the docs/ dir be a required part of making commits. uuid does something like this. The CI workflow builds the docs and fails if it results in any changed files.

0. Any browser
1. Upload package.json
2. Notice the URL bar and the search field
3. Refresh page and see nonsensical content

This is not a big bug, it's just a little annoyance because I have to empty the search field before searching again

Currently, the settings are not preserved, and they must be reset the next time opened, which is a bit annoying. I think it will be more intuitive if the settings can be persisted.

See npm/registry-issue-archive#34 (comment)

First of all, I really like npmgraph. It's dependency visualization is of great value!

Would it be possible to add a filter for an organization?

I would like to be able to only see the dependencies that are from my organization. For example, when I look for @wireapp/core, I want to just see the dependencies that start with @wireapp, so it will show me @wireapp/api-client, @wireapp/cryptobox, etc. but not tough-cookie or any other dependency which doesn't belong to my organization.

Testing Example: https://npm.broofa.com/?q=@wireapp/core

I haven't used npmgraph in a while but I'm pleasantly surprised by what it can do now!

However the military green is a little off-putting, would you consider using a fresher color palette?

• pahen/madge#289

This impacts npmgraph, but to a lesser extent because the graph you chose is slightly better in my experience.

I see this all the time. It's not a message the user should see

Hello,

It would be nice to have an option (e.g. a checkbox) to include development dependencies in the graph.

Thanks

First of all, thanks a lot for this awesome tool!

I just encountered a small issue while playing with the online version, dropping a package.json file does not seem to work, I get the following dialog popping:

Tested on chrome 63 and windows 10

As described in #24 (comment)

If you load a package.json file where any packages have versions specified as "*", then npmgraph will fail to handle those packages, presenting them as invalid references. (Yes, this is generally a bad thing for the package.json owner to do, but it's legal, and npmgraph should probably handle it.)

I'd like to use this graph over an npm module stored in a private repo on github that has a dependency that's also a private github repo, such as:

github:tranzmatt/my-project

package.json:

"dependencies": {
"project-dep": "github:tranzmatt/project-dep"
}

I have ssh and github token access, so how can I integrate that into npmgraph? Thanks.

The main use case would be to automate generation of the dependency graph without having to spin a browser and download the svg.

Ideally, this would be project-local script that would get installed as a dev dependency to be executed either manually or in a CI. The user API would be something like:

$ npmgraph --packages "foo,[email protected],baz" --output my-project-deps.svg

@fregante Thoughts on using parcel for code packaging? I've had good experiences with it, and will allow us to use actual React + JSX syntax instead of the kludgy notation currently needed for htm+preact.

FWIW, I've started porting the codebase over on my local box just to see how it feels and I'm inclined to keep going with it unless you have strong opinions to the contrary.

We're on Vercel's opensource plan. I'd like to get us on an opensource plan for bugsnag. Both companies ask for a sponsorship logo, so we should create a place for putting this sort of thing. Maybe on the "ⓘ" tab...?

And while we're at it we should add a "Sponsor NPMGraph Contributors" section of some sort.

windows 10. chrome latest
try to upload my package.json, i get this alert.
file must have .json extension

thanks for helping

The opposite of #38, some dependencies are noisy and it'd be best to exclude them from the tree.

From #35 (comment):

This is a good idea, but is non-trivial to implement. Please create issue and elaborate a bit more on how you'd like this to work. Specific questions:

• Would hiding a module subtree cause graph to re-render, or just leave blank space in the existing graph? (Asking because re-rendering large graphs is an expensive and blocking operation, so risks making for a very sluggish, unresponsive UI)

I think that parcel-bundler would leave quite large holes in the graphs, so while that'd be a fast operation, I'm not sure that it'd be the best way to display it

• Is hiding a module a persistent action? I.e. does it stay hidden in any subsequent graphs the user might go to?

I don't think anything else is persistent so why would this be any different?

• What does a hidden module look like in the graph? In the inspector?

The hidden module’s sub-dependencies would disappear from both, it would just display the sole module as if it had 0 dependencies. It would appear in both, marked as "hidden" somehow.

• ... and how might you unhide a module?

Hiding/unhiding would probably have to happen with a checkbox next to each dependency in the inspector, or as a select/dropdown where you can pick which packages to hide.

URL: https://npm.broofa.com/?q=is-number

The current deploy process is ... well... laughable. 'Happy to admit it. In my defense, I've been using this project as a bit of a sandbox to see how far one can push the limits of a static-file only, bundler-less, SPA.

But the time for that has past. If nothing else, having to use htm and preact's template-string-based, like-JSX-but-not-actually-JSX syntax is getting old.

Not sure what other's think, but I've been playing with Parcel and it seems to work pretty well. Setting that up as part of the build process, with a GH Action for deploying to the (coming soon) github pages version of this app probably makes sense.

just read from node-weekly, tried this one but not working?
http://npm.broofa.com/?q=@google-cloud/bigquery

it's valid one
https://www.npmjs.com/package/@google-cloud/bigquery

I just uploaded my package.json and enabled devDependencies. Needless to say, finding things is a little hard:

There are a few ways to make this easier:

• Adding a field above this list so that it can filter it and I can click one of the modules (which isn't currently fully working, it scrolls to the bottom left of the graph)

  

• Double-clicking on a module in the graph could "focus" on it, maybe simply by opening an explorer for that module in a new tab

• Hiding a dependency and all of its subs from the graph. There are just a few dependencies that ruin it for everyone else (like parcel-bundler with its 693 non-dev dependencies!)

Hi,
Thanks a lot for your awesome work !
Is it possible to specify a local npm server like verdaccio to be used with npm graph ?
Regards,
Blured.

There seems to be a mismatch in the number of packages reported between this project and npm install for some packages.

For example, when I install jest with npm in an empty folder I get this output:

added 525 packages, and audited 525 packages in 9s

Of course, this number includes jest itself, so I would expect the number of dependencies to be 524.

However, visualising it on npm.broofa.com only shows 474 dependencies. I'm trying to figure out where this discrepancy of 50 dependencies comes from.

One question I often have about a dependency graph is, "If I add/remove [module X], what dependencies actually get added / removed from the graph." I don't know of any tools that answer this particularly well, but I think we're well positioned to do so.

For example, we could enhance the current module selection to highlight the whole descendent dependency tree, rather than just immediate child dependencies. And, further highlight which of those dependencies are exclusive to the selected module. (i.e. which ones would actually get removed if the selected module is removed.)

#67 sort of does this in that when you collapse a module, any dependencies it shares with other modules will remain in the graph - but it's hard to see due to how the graph gets re-laid out.

@fregante I feel bad about how much I've dragged my feet on #50 and the other PRs you've put up. It has me realizing that I should probably step back and let you run with this. To that end, I'd like to propose the following...

• Create an "NPMGraph" github org and add you as an "owner"
• Transfer this repo to the new org
• npm owner add fregante so you can publish to NPM as needed
• Rename master branch to main (aligning with GH's new policy. See instructions for updating local repo branch name)
• Setup github.io page(s) (See https://npmgraph.github.io)
• Set up npmgraph.js.org (See js-org/js.org#5788)
• Redirect npm.broofa.com to ---^ (currently redirects to npmgraph.github.io. Will redirect to npmgraph.js.org once that's up and running)

Thoughts?

Semi-related image. We need night mode 😁

Deprecated+Colorized modules should have some sort of diagonal striping like their uncolorized counterparts. Currently they don't ...

Uncolorized:

Colorized:

If you use the import() function the website will be usable earlier (e.g. it can start resolving the graph) while it downloads this huge dependency.

docs/graphvizlib.d416b260.wasm      ⚠️  1 MB
docs/index.80c6c8bb.js                  368.92 KB   

0. Open Firefox or Safari
1. Visit http://npm.broofa.com/?q=webpack
2. Click any sidebar module link
3. Notice that the module is focused but the graph is always only scrolled to the bottom

It works correctly only in Chrome

I noticed that when comparing Avanka's npmgraph to yours that the count is lower here. I'm not entirely sure which one is correct, but I suspect it is Avanka.

As an example:

• npm.anvaka.com - puppeteer-core 1.20.0 - 43 nodes
• npm.broofa.com - puppeteer-core 1.20.0 - 40 dependencies

In particular:

Avanka includes:

* `[email protected]` from [email protected].
* `[email protected]` from [email protected].
* `[email protected]` from [email protected].

Whereas yours includes only [email protected] with all packages depending on some version of debug pointing to it, even those that require [email protected].

On large dependency trees it'd be useful to focus/extract only one dependency and its subs. This could happen on double-click on the tree or sidebar, by opening a new tab or just replacing the current tree (but it needs to be ctrl-z-able)

kind of like https://www.npmjs.com/package/npm-check

App at http://npm.broofa.com/ can't load second level of dependencies due to multiple CORS errors:

I noticed a long wait when clicking Show devDependencies in my package.json and you also seem to not like blocking the UI. I think that showing a little tab saying "Something is happening" would make it more bearable.

Personally I don't mind, but I don't want my wrist slapped again by suggesting it in #39

At present, for large graph, we can only use the scroll bar to view the complete graph, but it is not very convenient. It would be better to move the canvas directly.

1. Click https://npmgraph.js.org/
2. Click anywhere on the page to un-focus the field
3. Notice that the URL changed to https://npmgraph.js.org/?q=

No page works, no errors in the console

{"code":"INVALID_PARAMETER","message":"\"names\" must contain less than or equal to 250 items"}

Steps to reproduce:

1. Use this link as an example:
http://npm.broofa.com/?q=@vue/cli-plugin-babel

2. Open the web inspector and click on the network tab

3. Select NPMS.io maintenance score in the "Colorize by" select option.

4. Read the result from POST https://api.npms.io/v2/package/mget

Sometimes, arrows are not easy to follow due to overlap. It would be great if selecting a node could highlight the related nodes (both dependants and dependers, in different color). This would make it easier to use for situations like these screenshots:

A bunch of packages sharing common dependencies:

Packages being drawn misaligned with their dependencies and so curved edges overlapping a lot (this case might be avoided by reorganizing nodes though)

I've on more than one occasion seen a link to https://npm.broofa.com/, presumably by accident, out of habit, or perhaps due to some tools defaulting to HTTPS if no scheme is specified.

This is a request to kindly consider activate TLS on the server, and perhaps redirect to and/or promote by default the HTTPS variant in the README and repo description here on GitHub.

From the error page, it appears that the site is hosted at Dreamhost, which has a guide for using Let's Encrypt that might be helpful, and seems it will automatically use HTTPS by default.

Inspector:

• Auto-expand on module selection
• Handle no-such-module case
• Fix file drop

Graph pane:

• Fix npms.io colorization
• Fix truck factor
• Fix download-as-SVG
• Fix tag-highlighting in graph
• Fix <Section> expand/collapse

Module pane:

• Implement Module Pane

There's a few things about the current UI that bother me.

• As mentioned in #62, there's no good location for NASCAR stickers sponsor information
• The "ⓘ" (info) tab was supposed to be for that sort of thing, as well as copyright and license info, but is really just the upload-a-package.json tab now, (making the "ⓘ" symbol misleading 😢 )
• We jump through a lot of hoops with the inspector - auto-showing it, auto-switching tabs - that could be avoided if we used modal dialogs for that information.

I'm wondering if we couldn't just get rid of the inspector altogether and, instead ...

• Home screen (no graph)
• Graph screen
• Detail screen (for graph, module, or graph settings)

Test error in Example.com

ExampleException in home#example
Something really bad happened

View on Bugsnag

Stacktrace

app/controllers/home_controller.rb:123 - example
app/controllers/other_controller.rb:12 - broken
lib/important/magic.rb:4 - load_something

View full stacktrace

Created by Robert Kieffer via Bugsnag

Test error in Example.com

ExampleException in home#example
Something really bad happened

View on Bugsnag

Stacktrace

app/controllers/home_controller.rb:123 - example
app/controllers/other_controller.rb:12 - broken
lib/important/magic.rb:4 - load_something

View full stacktrace

Created by Robert Kieffer via Bugsnag

Error in NPMGraph

TypeError in /
version.replace is not a function

View on Bugsnag

Stacktrace

https://npm.broofa.com/js/Store.js:43 - Store.getModule

View full stacktrace

Created by Robert Kieffer via Bugsnag

npmgraph lets the user upload package.json files via UI but there's no way to share them. A packagejson parameter would also let anyone just pass the whole file.

You know this:

❯ npm i
npm WARN deprecated [email protected]: This module was renamed to text-field-exit. https://github.com/fregante/text-field-edit/releases/tag/v3.0.0
npm WARN deprecated [email protected]: request-promise-native has been deprecated because it extends the now deprecated request package, see https://github.com/request/request/issues/3142
npm WARN deprecated [email protected]: Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated [email protected]: this library is no longer supported
npm WARN deprecated [email protected]: Please update to v 2.2.x
npm WARN deprecated [email protected]: https://github.com/lydell/resolve-url#deprecated
npm WARN deprecated [email protected]: Jetpack extensions are no longer supported by Firefox. Use web-ext instead to build a WebExtension.
npm WARN deprecated [email protected]: fsevents 1 will break on node v14+ and could be using insecure binaries. Upgrade to fsevents 2.
npm WARN deprecated [email protected]: Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.
npm WARN deprecated [email protected]: Package no longer supported. Contact [email protected] for more info.
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated @babel/[email protected]: 🚨 This package has been deprecated in favor of separate inclusion of a polyfill and regenerator-runtime (when needed). See the @babel/polyfill docs (https://babeljs.io/docs/en/babel-polyfill) for more information.
npm WARN deprecated [email protected]: Critical security vulnerability fixed in v0.21.1. For more information, see https://github.com/axios/axios/pull/3410
npm WARN deprecated [email protected]: core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.

I haven't found a way to see where these packages come from, then I remembered about npmgraph. Unfortunately, npms.io’s score doesn't consider deprecation (npms-io/npms-analyzer#257), so my deprecated module appears as fully green: http://npm.broofa.com/?q=insert-text-textarea

What do you think about marking deprecated modules as red or even a deeper red color? npmgraph would be a great tool to find why subdependencies in my app have been deprecated