Moment Js Bundle Laravel Package

Product Decisions This Supports

Primary decision: do not adopt — this is a "no-build" call, not a "buy" call. The package is a thin Symfony 2 bundle whose only job is to ship moment.js into the asset pipeline via a DI extension and config. It is not a date-handling library, not a Laravel package, and not a maintained dependency. It informs the following product decisions:

• Front-end date/time library selection (build vs. buy): The real decision this surfaces is which JS date library we standardize on. Moment.js has been in maintenance/legacy mode since 2020 — the maintainers themselves recommend Day.js, Luxon, date-fns, or native Temporal for new work. This package would lock us into a legacy library with no tree-shaking (Moment ships locales as a monolith, ~60–70 KB min+gzip depending on build).
• Asset delivery strategy: Whether front-end assets come from Composer (Symfony bundle/Assetic era), from npm via Vite/Webpack (Laravel default since Laravel 9+/Vite), or from a CDN. This package represents the old answer; adopting it re-legitimizes Composer as an asset channel and creates a second, unpinned supply chain.
• Framework-alignment / migration planning: If roadmap includes Symfony 2 → Laravel or Symfony 2 → Symfony 6/7 migrations, this bundle is dead weight in both directions. It argues for standardizing on framework-agnostic npm packages so asset choices survive framework migrations.
• Legacy-stack triage: The only genuine product use case is a triage decision on an inherited Symfony 2.x codebase — "do we keep patching the old front-end or fund a Vite migration?" This package's existence is a data point for funding the migration, not a solution.
• Roadmap / dependency policy: Reinforces a rule that dependencies must have (a) a release in the last 24 months, (b) at least one active maintainer, (c) a security update path, and (d) a documented framework-version support matrix. This package fails all four.

Opportunity score caveat: The 4.16 "opportunity" figure should not be read as adoption signal. With 0 stars, 0 dependents, and a July 2015 last release, it most plausibly reflects an empty niche (no modern, maintained Composer-side date-asset integration), not readiness. Do not put this in a roadmap as a candidate dependency.

When to Consider This Package

Consider it only under a narrow, largely historical condition set — and even then, prefer alternatives:

• You are maintaining a Symfony 2.x application (PHP 5.5–7.x era) with an Assetic/assets:install workflow, and you need moment.js available as a Twig-accessible asset without introducing npm/Node into the build.
• The app already uses Moment.js, and you need to make its version explicit and Composer-managed rather than a hand-copied web/vendor/ file.
• You accept zero upstream support: no security patches, no PHP 8 compatibility guarantees, no Moment.js version bumps, no issue triage.

Look elsewhere — decisively — if any of the following is true:

Recommended replacement pattern instead of this package: add the date library as an npm dependency and bundle it through Vite (Laravel's default) or Webpack Encore (Symfony's modern default). That gives version pinning, lockfile integrity, tree-shaking, and a path that survives a framework migration. If a Composer-only constraint is truly immovable, vendor a pinned moment.min.js into resources/ directly — you get identical behavior with one less abandoned abstraction and no false sense of maintenance.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated stinger/moment-js-bundle and recommend against adoption. It is a ten-year-old Symfony 2 wrapper around Moment.js, with no stars, no downstream dependents, and no release since July 2015. It provides no capability we can't get in three lines of front-end configuration, and it would introduce an unsupported dependency into our stack with no security-patch path — a standing compliance and upgrade liability disproportionate to the tiny convenience it offers. Crucially, it is not a Laravel package, so using it in our Laravel services would require custom glue code to adapt a Symfony bundle to Laravel's service provider model. The strategic recommendation is to standardize date handling on a maintained, framework-agnostic library (Day.js or Luxon) installed via npm and bundled through Vite. Cost: roughly a day of front-end work. Benefit: no abandoned dependency, no rework at the next framework upgrade, and a smaller JS payload.

For engineering leads: Treat this as a rejected dependency, but capture the two useful signals. First, if any legacy Symfony 2 service still hand-vendors moment.js, this is the moment to pin it explicitly and schedule migration to Day.js — the API is close enough that most call sites are mechanical. Second, add a dependency-health gate to our review checklist: last release within 24 months, at least one active maintainer, documented supported framework/PHP matrix, and a security-response path. This package fails all four, and the failure is silent — 0 dependents means no one will file the CVE for us.

For the requesting team: If the underlying need is "make Moment.js available as an asset without adding Node to the build," tell us that specifically — the answer is a pinned vendor file in resources/, not a Composer package. If the need is "consistent date formatting and relative-time display across our apps," we'll scope a shared front-end utility module on Day.js. Either path is smaller than adopting and maintaining a 2015 Symfony bundle, and neither one leaves us owning someone else's abandoned code.