we haven’t launched yet! we’re building openly but aiming for march 3. as is par for the course, hn gets the scoop.
i made the first commit two weeks ago, so it’s very new. but we’ve had 900+ PRs and 170+ contributors in the last fortnight… because this is something we care about.
having said that, i’m taking notes about what is and isn’t intuitive
npmjs remains the source of truth for the registry, which is why we get our data from there
but along the way we add a lot of features, like: - claiming new packages from the ui - batch admin operations for your orgs, teams and packages - total install size, vulnerabilities and deprecations for your transitive dependencies - generated docs for packages - linkable package contents - and more
There are many ways to get more visual hierarchy and I wish you make use of them.
I will be thinking closely and I really prize all thoughtful feedback like this.
we're currently on a collective holiday: https://npmx.dev/recharging. but when we're back, you would be really welcome to join us and make it better - if you want!
it's open source at https://github.com/npmx-dev/npmx.dev
npmjs.com is not slow and not something I need to interact with very often.
And npmjs.com is still the authority when it comes to publishing packages, no? So I'd still have to use it.
I'd say the probability that some thought has gone into this project it pretty high. Your reply stating that this was created without any though or effort is, ironically the least thoughtful, laziest and least useful response possible.
Me personally, I’m writing tools for myself wouldn’t have bothered with before due the the time investment needed.
Minor edge case, but infuriating if you want to check your own packages quickly (without needing to navigate menu > packages > YOUR_PACKAGE).
Still agree with you though, who is npmx actually for?
I have had the thought "NPM search sorted by downloads this week is giving me irrelevant packages" - but I'm not sure this tool solves that.
No idea where I found this but I’ve been using for many, many years.
Furthermore... I don't host my packages on Github :-) Don't think that even works for mine.
Awful comment. Your comment is bad and should be ashamed.
Use it and disagree! Tell me it in fact does not spark more joy! This just seems pretty clear, ya'll.
It's just generally vastly nicer. I love that file exploration of packages doesn't feel like a last afterthought before leaving the solar system forever.
Another could be to have an "alternatives" section based on semantic similarity and / or some other features that have signal.
https://www.npmjs.com/package/vue
Decide for yourself which UX is better.
Compare your npmx link to vue to https://npmx.dev/package/node-red-contrib-rtc-alert-node . This package uses deprecated and vulnerable deps and npmx correctly uses color to draw attention to it. And because the npmx page is normally monotone, the use of color actually draws your attention.
Regarding clutter - I agree.
> `[nuxt] Cannot load payload /package/@storybook/addon-docs/_payload.json?c459501f-8eb7-49c9-be9c-4a197fa35a39 Error: Invalid input`
- Scrolling fast on Firefox + Chrome is broken and resets the search results page to start.
- Pressing up/down arrows should navigate search item results instead of focusing individual tag elements.
Edit: it wants me to connect to the “atmosphere” - is this the Bluesky App Store thing? I really don’t see how linking my socials to npm search makes sense.
Nit: there are distracting animations, such as on the weekly download graph.
I've always defaulted to using https://yarnpkg.com/ to search for packages cause the npmjs.com search is so slow, but while the yarnpkg.com search is super fast, actually clicking on a package and seeing the details page takes forever.
This is super fast for both search and the details page, and it's super keyboard friendly which makes it even faster to use in practice. Definitely going to become my go-to search now. Love it, thanks for building it!
As someone who spent a year obsessing over performance in a .NET MAUI app (IMAP processing, background execution, API latency), I know how hard it is to shave milliseconds off search. The npm registry is massive, and you're clearly doing something right on the indexing or caching side.
Are you using client-side filtering with a pre-built index? Server-side with some clever caching strategy? I'm genuinely curious about the architecture choices that got you to "uncannily fast" territory—especially compared to the official npmjs.com search.
Whatever you're doing under the hood, it shows. Performance is a feature.
> It's good npmx.dev shows git and https dependencies. I still think it's crazy npmjs.org doesn't.
https://bsky.app/profile/dsherret.bsky.social/post/3mer2diwj...