Js Bundle Laravel Package

Product Decisions This Supports

• Framing the "server-to-client state bridge" as a product problem, not a package decision. The recurring need — putting route config, feature flags, translations, and current-user context into one predictable global JS object — shows up in nearly every server-rendered app with progressive enhancement. This package is a reference implementation of that pattern, useful as a design input for scoping the problem even if the code is never installed.
• Build vs. buy vs. steal for config injection. In Laravel the problem collapses to roughly 20 lines: View::share, a Blade <script>window.App = @json($config)</script>, or a small service provider plus a Blade directive. The existence of a dedicated bundle is evidence the need recurs across teams — not evidence a team needs a dependency to solve it.
• Roadmap signal for Inertia/Livewire versus hand-rolled JS glue. If the roadmap is moving toward Inertia or Livewire, page-props and component state handle the bridge in the adapter layer. If the product stays on Blade plus vanilla ES modules, a small in-house convention is required. This package sits in the shrinking middle ground between those two futures.
• Standardization decision for i18n, flags, and auth bootstrapping. The decision worth making is to standardize on one documented global object with one place to add keys — otherwise i18n, feature flags, and authenticated-user bootstrapping each invent their own inline <script> blocks and their own escaping bugs.
• Security posture decision (allowlist enforcement, CSP compatibility). Choosing between an inline synchronous global and a JSON <script type="application/json"> island is a product-level decision about CSP strictness, cacheability, and page-weight budget, not an implementation detail.

When to Consider This Package

Consider adopting only if all of the following hold — which is unlikely for a Laravel product:

• The product runs a Symfony 2.x application. This is a Symfony bundle, not a Laravel package — there is no service provider, facade, or Blade directive, and Laravel's bootstrap never invokes a bundle entry point. Symfony 2.8 reached end-of-life in January 2019, so this implies a legacy modernization context with no appetite for a rewrite.
• There is appetite to own an effectively unmaintained artifact: 4 stars, 0 dependents, package score 0.02 means no community validation, no security review, no issue triage, and no upstream escalation path. Budget for vendoring or forking.
• A license has been confirmed (an absent LICENSE file means default copyright applies, which blocks internal redistribution).
• The bundle's conventions — global object shape, PHP-value serialization, escaping — have been reviewed and match the security posture. A global object is an XSS-adjacent surface; </script> breakout and secret leakage are the two highest-severity failure modes.

Look elsewhere (or build in-house) when:

• The stack is Laravel 10/11 + PHP 8.2/8.3. Composer pins symfony/* to ^6/^7; a bundle declaring symfony/symfony ~2.3 cannot co-resolve, and the Symfony 2 code itself likely trips on PHP 8 removals (each(), create_function(), curly-brace string offsets).
• Maintained tooling exists: Blade @json/@js, Ziggy for named routes, Inertia's HandleInertiaRequests::share(), Vite define/import.meta.env for build-time constants, and an explicit opt-in allowlist in a service provider for anything broader.
• Typed or validated PHP↔JS contracts are needed. Prefer TypeScript type generation or an OpenAPI-derived client over an untyped global object.
• Security or compliance review is a gate; single-maintainer code with no dependents will not clear it.

How to Pitch It (Stakeholders)

Recommendation: adopt the idea, reject the dependency. Reimplement the pattern in-house in roughly one engineering day.

ite/js-bundle is a Symfony 2 bundle — not a Laravel package — from an end-of-life framework generation, with negligible adoption (4 stars, 0 dependents), a near-zero package score, and no maintenance signal. On a Laravel codebase it cannot be installed without adaptation work exceeding the cost of writing the equivalent ourselves; a composer require will fail dependency resolution at best and produce a subtly broken autoloader at worst.

The problem it addresses is legitimate and recurring: getting server-side config — routes, flags, i18n strings, current user — into the browser in one predictable place. We should solve that deliberately with a small, tested in-house convention: a service provider exposing an explicit allowlist (never a denylist), a Blade directive or JSON <script type="application/json"> island, JSON_HEX_TAG|JSON_HEX_AMP|JSON_HEX_APOS|JSON_HEX_QUOT on encode, and a test asserting that secrets such as DB_PASSWORD, APP_KEY, and any *_SECRET can never be emitted. If the roadmap moves to Inertia or Livewire, that layer owns the bridge instead and we build nothing.

Cost of the recommended path: about one engineering day including tests and docs, versus indefinite ownership of a fork of an unmaintained EOL bundle. Low effort, low risk, and it leaves us free to migrate to a richer adapter later.

Three levers to govern once it ships, because this pattern has a history of production incidents:

• Payload size — every byte in the global is uncacheable HTML on every response. Set a CI budget (e.g. under 30 KB) and fetch large route or translation tables lazily.
• Cache correctness — the moment per-user data enters the global, the response is user-specific. Full-page caches, CDNs, and Cache-Control: public must be partitioned or disabled. This is the most common way the pattern breaks in production.
• Secret leakage and XSS — enforce an allowlist, check the return value of json_encode (non-UTF-8 data returns false), and pair the payload with a CSP that uses a nonce rather than unsafe-inline.

Follow-up if any stakeholder wants to pursue the package itself: confirm the license, identify exactly what the emitted global contains (config scalars, translations, routes, or arbitrary container services — this determines the blast radius of a leak), and check whether any branch targets Symfony 4/5/6. Without a positive answer to the last question, the port is a clean-room rewrite, not an upgrade.