5 ms·

Congrats on shipping it! This got me thinking about what the existing cookie libraries looked like in npm, since I figured it was a solved problem already, pot

Congrats on shipping it! This got me thinking about what the existing cookie libraries looked like in npm, since I figured it was a solved problem already, potentially even with the exact same API. There are a lot of cookie libraries for the browser in npm! Here are the ones I found, grouped by what syntax they end up implementing, and showing their current downloads per month... Using the .get() .set() .remove() syntax: js-cookie (141,938) cookies-js (36,319) cookie-cutter (8,848) cookie-monster (7,457) client-cookies (216) cookie-browser (198) cookie-handler (118) juicy-cookie (115) cookies-es5 (109) cookie.js (84) mmm-cookies (41) cookie-crisp (60) easy-cookies (13) Using the Web Storage syntax: cookie-storage (1,101) mozilla-doc-cookies (491) cookiestorage (27) Using the almost-Web-Storage syntax: oven (111) Using the `(get, set) syntax: component-cookie (7,360) cookee (1,568) Using your syntax: cookiesjs (49) I think it's a good example of npm's problem as a search engine for packages. Realistically all of these libraries have the same goal, and probably achieve it equally well. A few have better browser support, a few have better docs, a few have better tests, etc. No one should be prevented from creating and publishing whatever they want as a library. But npm should be doing a much, much, much better job at pointing people towards the popular libraries. It takes a lot of work to figure out what cookie libraries to use. Or what snake-case library to use. When it really shouldn't. You could easily eliminate most of these libraries with a few simple metadata checks. And I think it's incredibly unfortunate that npm isn't pushing people in that direction.

niftich 10y ago
I think you raise a good point, but when has this been the package manager's concern? When I type in 'dnf search' or 'apt-get install' or 'pip search' or the equivalent, I don't get details, I just get a list of packages, one of whose title or description fields match what I pass on the command-line. A package's exported API is important (obviously, since without it you can't use it), but I'm not entirely sure the package manager is the best place to surface this information. Or maybe it should be, but no package manager so far does this well?
- ianstormtaylor 10y ago
  Yup, I don't think any package manager has ever really done this well. But what makes the problem worse is that npm advocates using lots of small modules, and using them in an environment (the browser) where duplication weight has big negative consequences. I think there's a real opportunity to unseat npm if someone applied to same kind of UX-first thinking to package management that has been applied to other areas.
tracker1 10y ago
I kind of agree.. the search on npm isn't very good, I get better from google with site: option. Beyond that, it would be nice if results could be sorted by downloads/month, freshness, frequency of updates, and github issues. Even just downloads/month on the search results screen would be helpful, as well as repo link... I usually look at downloads and gh issues as the canary for health, which is usually a good indicator.
- jazoom 10y ago
  It's absolute garbage. More than once I've not been able to search for a package with the exact spelling. Google usually guides me to the page, or manually manipulating the URL.
zachrose 10y ago
Maybe that's an opportunity for someone or something, like The Wirecutter[1] for npm. [1] http://thewirecutter.com/ http://thewirecutter.com/

niftich 10y ago

I think you raise a good point, but when has this been the package manager's concern? When I type in 'dnf search' or 'apt-get install' or 'pip search' or the equivalent, I don't get details, I just get a list of packages, one of whose title or description fields match what I pass on the command-line. A package's exported API is important (obviously, since without it you can't use it), but I'm not entirely sure the package manager is the best place to surface this information. Or maybe it should be, but no package manager so far does this well?

ianstormtaylor 10y ago
Yup, I don't think any package manager has ever really done this well. But what makes the problem worse is that npm advocates using lots of small modules, and using them in an environment (the browser) where duplication weight has big negative consequences. I think there's a real opportunity to unseat npm if someone applied to same kind of UX-first thinking to package management that has been applied to other areas.

tracker1 10y ago

I kind of agree.. the search on npm isn't very good, I get better from google with site: option. Beyond that, it would be nice if results could be sorted by downloads/month, freshness, frequency of updates, and github issues. Even just downloads/month on the search results screen would be helpful, as well as repo link... I usually look at downloads and gh issues as the canary for health, which is usually a good indicator.

jazoom 10y ago
It's absolute garbage. More than once I've not been able to search for a package with the exact spelling. Google usually guides me to the page, or manually manipulating the URL.

zachrose 10y ago

Maybe that's an opportunity for someone or something, like The Wirecutter[1] for npm. [1] http://thewirecutter.com/ http://thewirecutter.com/