Common JS Libraries

Features

• Over 40 common libraries in fourteen categories: dates, requests, utilities, state, forms and validation, charts, UI and styling, animation, graphics and 3D, documents, text, editors, build and test, misc
• Search by package name: enter dayjs for its purpose, category, install command and package page
• Search by purpose: enter "charts" or "drag" to see the options in that area
• Search by category to list everything of that kind
• A copyable install command (`npm i dayjs`) and package page for each
• Both the install command and the page are derived from the package name, so neither can be wrong or out of date
• Package names stay as they are on the English page — they are what you type into a terminal
• All package names sit in a searchable dropdown, with the category in the hint
• Empty input lists everything, grouped into the fourteen categories
• Paste tolerance: quotation marks and full-width characters do not break the lookup

How to use

1. Enter a package name, such as dayjs, for its purpose, category and install command
2. Or enter a purpose, such as "charts", to see what the options are
3. Enter a category, such as "state management", to list everything of that kind
4. Leave the box empty to list everything, grouped into fourteen categories

FAQ

Why are there no version numbers?

Because a version number is the one piece of information here that goes stale immediately. Any list with hard-coded versions starts ageing the day it is published, and having someone install an old version is worse than not telling them — `npm i dayjs` always gets the current one, with the exact version decided by npm and your lockfile. Homepages are left out for the same reason: projects change domains, move to subdomains and rename, and none of that can be derived from the package name. The package page is the one locator that can be, so it is the only one given.

How were these chosen, and why is some library missing?

The criterion is "does this problem have an obvious default answer", not star count — stars change, and popular is not the same as suitable. So every entry is the one most often reached for in its area (echarts for charts, dayjs for dates, axios for requests). Missing does not mean bad: libraries that only matter inside one framework, ones that need a backend, and ones with a short remaining life are all left out. And only packages that certainly exist are included — better one fewer than a name that might be right.

lodash or es-toolkit?

New projects can go straight to es-toolkit: it provides the commonly used half of lodash in a much smaller package, with native ESM and complete TypeScript types. Two good reasons to stay on lodash: the project already uses it and the migration costs more than it saves, or you need deep property access like `_.get` or an obscure helper that es-toolkit has not covered. Either way, import individual functions rather than the whole package — pulling in all of lodash visibly inflates a first load.

Is everything here free to use?

Not necessarily — check before you commit. Most of these are under permissive licences such as MIT or Apache and are unrestricted for commercial use, but a few need care: GSAP has a free core with some plugins under different terms, map libraries split between a free renderer and a metered service, and some charting libraries offer commercial editions. Licences change, so confirm the current one on the package page before shipping, especially commercially — that is not something this table can guarantee on your behalf.

Why does the editor entry mention that this site uses CodeMirror?

Because that entry states it as one datapoint for the choice. The CodeMirror versus Monaco trade-off is a good illustration: Monaco is the editor core behind VS Code, with the strongest IntelliSense and syntax highlighting, but it is several megabytes and its mobile support is limited. CodeMirror 6 is far smaller and works on mobile, at the cost of wiring up completion yourself. This site only needs a text box with highlighting, hence CodeMirror — if you are building a full IDE experience, Monaco is the better fit.