The moment npm package is in maintenance mode, which means it still receives critical security fixes but no new features, and its own maintainers now discourage using it in new projects. If you searched for moment js npm expecting the go-to date library, the honest 2025 status is more nuanced: moment is a legacy project, not a dead one. It is not a security emergency, but it is a signal to stop reaching for npm i moment on greenfield work and to plan a path off it where the cost is low.
What "maintenance mode" actually means
The Moment team has been explicit. The project is done, not dead. Concretely, per the maintainers:
- They will not add new features or change the API to be immutable.
- They will not fix tree-shaking or bundle-size issues; there will be no version 3.
- They will address critical security concerns as they arise.
- Moment-Timezone will keep getting IANA time-zone database updates.
So from a pure security-triage standpoint, npm moment is in a reasonable place: critical vulnerabilities still get patched. The concern is not "moment.js will leave a known CVE unfixed." The concern is everything else about depending on a frozen library.
The real problems with moment
The reasons the moment js npm package fell out of favor are architectural, and they matter for maintainability as much as security:
Bundle size. Moment does not tree-shake. If you need internationalization or time-zone support, the library and its locale data balloon your bundle. It is common to ship 70KB or more for what modern alternatives do in a fraction of that. Larger bundles are slower, and slow is its own kind of operational risk.
Mutability. Moment objects are mutable. Calling a method like .add() mutates the original instead of returning a new value, which produces hard-to-diagnose bugs where a date changes underneath code that assumed it was stable:
const start = moment('2025-01-01');
const end = start.add(1, 'month'); // mutates `start` too!
// start is now 2025-02-01, not 2025-01-01
That footgun has caused real incidents. It is not a CVE, but a date silently shifting in a billing or scheduling calculation is a genuine correctness-and-trust problem.
Frozen surface area. A dependency that will never modernize is technical debt that only grows. Every year it stays, the eventual migration gets a little larger and the ecosystem support a little thinner.
When it is fine to keep moment
Pragmatism matters. Moment is well established in millions of projects, and ripping it out on principle is not always the right call. It is reasonable to keep npm moment js when:
- The app is mature, moment is deeply woven in, and the date handling works.
- You are not shipping the library to size-sensitive clients (a backend job, for instance, where 70KB is irrelevant).
- You keep it patched and pinned, and you have no active feature work that would grow the moment footprint.
Maintenance mode plus security patches means an existing, working moment dependency is not a fire drill. Update it, pin it, move on. Just do not reach for it on anything new.
What to migrate to
When you do move, three replacements have effectively absorbed moment's role, each with a different flavor:
- Day.js — a near drop-in with a moment-like chaining API at roughly 2KB. The easiest migration if you want minimal code churn.
- date-fns — a functional, tree-shakeable toolkit where you import only the functions you use. Best bundle characteristics; a different mental model.
- Luxon — created by a member of the Moment community, with a familiar chaining API but immutable objects, fixing moment's biggest footgun.
For a mechanical migration, Day.js usually costs the least. For a codebase where you want to shed the mutability bugs and modernize, Luxon or date-fns is the better long-term home. Migrate incrementally: introduce the new library for new code, convert modules as you touch them, and delete moment when the last import is gone.
Treat it like any supply-chain dependency
Whatever you decide, apply the same hygiene you would to any package:
- Pin the exact version in your lockfile and commit it.
- Let a dependency scanner watch for advisories so a future critical fix is not something you discover late. An SCA tool flags a vulnerable moment version even when it is pulled in transitively by another library, which is common.
- Audit whether moment is even directly used or just riding along as a transitive dependency you could eliminate by upgrading its parent.
The bottom line for 2025: the moment npm package is safe to keep in existing projects thanks to ongoing security fixes, but its maintenance-mode status, bundle weight, and mutability make it the wrong default for new work. Keep what works, patch it, and default new code to a modern alternative.
FAQ
Is the moment npm package deprecated?
Not exactly. It is in maintenance mode, which the maintainers describe as "done, not dead." No new features and no major versions, but critical security fixes and time-zone data updates continue. The team discourages using it in new projects.
Is moment.js a security risk?
Not inherently. Critical vulnerabilities still get patched, so a pinned, up-to-date moment is not a security emergency. The bigger concerns are bundle size, mutable objects causing bugs, and the accumulating cost of depending on a frozen library.
What should I use instead of moment?
Day.js for a near drop-in replacement with a tiny footprint, date-fns for a functional, tree-shakeable approach, or Luxon for a moment-like API with immutable objects. Day.js is usually the cheapest migration.
Do I need to remove moment from existing projects immediately?
No. If it works and stays patched, an existing moment dependency is fine to keep. Prioritize migration for size-sensitive frontends or where mutability bugs bite, and default new code to a modern library rather than adding more moment usage.