Handle objections directly.

General

• What is mmntjs?
• Is it a drop-in replacement for moment.js?
• Why does this exist if moment.js still works?
• Is it production-ready?
• What is the long-term goal?

Compatibility

• How compatible is it with moment.js?
• What APIs are not supported yet?
• Are invalid dates handled the same way?
• Does it preserve mutability semantics?
• How does parseZone behave?
• Does it include moment-timezone behavior?

Migration

• How should we migrate safely?
• Can we replace moment globally?
• Should we migrate service-by-service?
• How do we detect risky usage?
• What tests should we run before adoption?

Performance

• Is mmntjs faster than moment.js?
• How are benchmarks run?
• Are results reproducible?

Package Size

• Is bundle size smaller?
• Which entry point should browser apps use?
• Does timezone data ship with core?

Ecosystem

• Why not Temporal?
• Why not dayjs?
• Why not date-fns?
• Why not Luxon?
• Can mmntjs coexist with those libraries?

Maintenance

• What is the versioning policy?
• How are breaking changes handled?
• How are compatibility bugs prioritized?
• How can users report differences from moment.js?

What is mmntjs?

mmntjs is a compatibility-first date/time library intended for teams that still depend on moment.js behavior but want a safer path forward. It is positioned as a migration bridge, not as a claim that every codebase should stop at this library permanently.

Is it a drop-in replacement for moment.js?

For common moment.js usage, yes: the goal is unchanged imports and moment-compatible behavior. Do not assume perfect coverage for every edge case. Check the Compatibility and Known Differences pages before replacing moment across a large codebase.

Is this production-ready?

It is ready for serious evaluation in production-like test environments, not for blind replacement in every codebase. Start with a low-risk module, compare behavior against your fixtures, and expand only after compatibility-sensitive paths are boring.

How compatible is it with moment.js today?

Strong enough to evaluate seriously. Upstream moment.js compatibility tests pass, timezone compatibility tests pass across multiple timezones, and fuzz/property tests compare against moment.js. The remaining known gaps are mostly unusual parsing edge cases, not broad API categories.

What APIs are not supported yet?

Core mmntjs does not include full named IANA timezone behavior. Use mmntjs-timezone for moment-timezone-style APIs. If your app depends on obscure plugin behavior or odd forgiving parse inputs, check it explicitly instead of assuming it is covered.

Are invalid dates handled the same way?

The intended behavior is to match moment.js. Invalid dates are tested because they affect formatting, comparisons, and control flow. If your application intentionally relies on invalid inputs, add those exact inputs to your migration test set.

Does it preserve mutability semantics?

Yes, preserving moment.js-style mutability is part of the compatibility goal. That matters because many existing codebases rely on mutation through add, subtract, startOf, endOf, setters, and shared object references even when the code does not make that dependency obvious.

How does parseZone behave?

It preserves fixed offsets like moment.js. Offset parsing, offset display, utcOffset, and keepLocalTime behavior are tested against moment.js. If parseZone is important in your app, test real examples from production logs or fixtures.

What is still known to differ?

Pre-release: known differences exist and are tracked. Standard ISO, RFC 2822, format, UTC, offset, and duration behavior are the main compatibility targets.

Why not just use Temporal?

Temporal is the long-term direction for many teams, but it does not solve the short-term problem of replacing a large mutable moment.js surface in one step. mmntjs is meant to lower migration risk now while giving teams more time to move new code toward modern APIs later.

Why not dayjs, date-fns, or Luxon?

Those libraries can be good choices for new systems or for teams ready to change calling patterns. mmntjs is aimed at a narrower problem: preserving legacy moment.js behavior closely enough that a large rewrite does not have to happen first.

Does it include timezone data?

Core mmntjs does not bundle named IANA timezone data. It supports UTC and fixed-offset behavior. Use mmntjs-timezone when you need moment-timezone-style named zones.

How should we migrate safely?

Start with inventory and compatibility review, then replace imports in a small owned surface, run existing tests, add a few targeted comparisons around parsing and timezone behavior, and expand only after those checks are boring.

Can we replace moment globally?

Sometimes, but it should not be the default recommendation. A global replacement can hide where the risk really is. Module-by-module or service-by-service rollout usually produces clearer ownership, easier rollback, and more trustworthy migration evidence.

Should we migrate service-by-service?

Usually yes for large systems. Service-by-service or package-by-package migration keeps ownership clear, makes rollback smaller, and lets high-risk parsing, locale, and timezone paths stay on moment.js until they have enough evidence.

How do we detect risky usage?

Look first for custom parsing, forgiving string inputs, invalid-date checks, timezone or parseZone usage, locale-sensitive output, mutation-heavy chains, and reporting or billing boundaries. Those are the places where date-library migrations usually fail quietly.

What tests should we run before adoption?

Run the tests you already trust first. Then add targeted checks for custom parsing, invalid-date behavior, timezone and DST transitions, parseZone or keepLocalTime flows, and any locale-sensitive formatting that reaches users or reports.

Is mmntjs faster than moment.js?

In the current benchmark set, yes. mmntjs wins the tracked moment.js operations, with especially large wins in ISO parsing, common formatting, diff, getters, and simple arithmetic. Treat this as benchmark evidence, not a promise about every workload.

How are benchmarks run?

Benchmarks use process.hrtime.bigint(), warmup runs, repeated medians, consumed outputs to avoid dead-code elimination, and separate cold/warm measurements. Results are checked on Bun and key rows are cross-validated on Node.

Is bundle size smaller?

Tree-shaking works. mmntjs declares sideEffects:false and locales are pure data with no auto-register side effects, so bundlers remove unused code. The bundle cost is whatever your app actually imports, not a fixed number.

Can mmntjs coexist with dayjs, date-fns, Luxon, or Temporal?

Yes. mmntjs is a migration bridge for legacy moment.js usage, not a rule that every date call in a system must use one library. Teams can keep mmntjs around old moment-shaped code while using other libraries or Temporal for new code where they fit better.

How are breaking changes handled?

Any behavior change that affects moment.js compatibility should be documented. Even small parsing, formatting, invalid-date, timezone, or mutability changes can matter during migration, so they belong in release notes or known-difference docs.

How are compatibility bugs prioritized?

Compatibility bugs are high priority. Bugs in parsing, formatting, invalid-date handling, timezone behavior, offsets, locale output, or mutation semantics matter more than cosmetic API work because they can break existing moment.js code silently.

How can users report differences from moment.js?

The most useful report includes the exact input, the moment.js output, the mmntjs output, runtime and timezone settings, and whether locale or timezone packages are involved. Small reproducible fixtures are much more valuable than broad descriptions of date drift.

What is the long-term goal?

The long-term goal is to get teams off unmaintained moment.js usage without forcing a risky rewrite. mmntjs is a bridge: keep old behavior stable first, then move new code toward better APIs such as Temporal where that makes sense.