Require Js Bundle Laravel Package

Getting Started

Read this first: hearsay/require-js-bundle is a Symfony2 bundle, not a Laravel package. It is archived, has zero dependents, and targets a pre-Symfony 4 / pre-PHP 8 era. There is no service provider, no package discovery, and no supported composer require path into a modern Laravel app. Your day-to-day leverage is therefore not "install and use" — it is "mine the config schema and reproduce the behavior natively."

Minimal steps for a Laravel developer:

1. Do not add it to composer.json. You will drag in old Symfony components and risk dependency conflicts with the Laravel runtime.
2. Where to look in the repo, in order:
   • DependencyInjection/Configuration.php — the config schema (baseUrl, paths, shim, deps, map, waitSeconds) you should mirror.
   • RequireJs/ — the core config/optimizer classes; explains how the final require.config payload is assembled.
   • Resources/config/ — Symfony DI wiring; read only if you need to understand the assembly order.
   • Twig/ — the extension that emits script tags and config; gives you the exact output shape to replicate in Blade.
   • README.md — Symfony2 install steps (AppKernel, config.yml); reference only.
3. First use case (Laravel): install requirejs from npm, drop require.js into public/js/vendor/, define config/requirejs.php from the bundle's schema, and render it from your layout:

<script src="{{ asset('js/vendor/require.js') }}"></script>
<script>
    require.config(@json(config('requirejs')));
    require(['app/page']);
</script>

4. First use case (legacy Symfony2): register the bundle in AppKernel, add hearsay_require_js under config.yml, and let the bundle's Twig helper emit config + script tag. Wire one page/module before touching the optimizer.

The bundle's real value to you is its config blueprint, not its runtime.

Implementation Patterns

1. Native Symfony2 usage (the only supported path)

The bundle assumes config-driven path/shim definitions and a Twig helper to render them:

# config.yml
hearsay_require_js:
    base_url: "js"
    paths:
        app: "app"
        jquery: "vendor/jquery"
    shim:
        jquery:
            exports: "$"

Day-to-day rule: keep all module IDs and paths in config, never inline in templates. That is what makes repeatable builds possible and what the optimizer reads.

2. Laravel translation: config file + Blade directive

Mirror the schema 1:1 in config/requirejs.php so your mental model transfers:

return [
    'baseUrl' => '/js',
    'paths' => [
        'app' => 'app',
        'jquery' => 'vendor/jquery',
    ],
    'shim' => [
        'jquery' => ['exports' => '$'],
    ],
];

Expose it once via a directive so pages never repeat require.config():

// app/Providers/AppServiceProvider.php
Blade::directive('requirejs', function () {
    return "<?php echo '<script>require.config(' . json_encode(config('requirejs')) . ');</script>'; ?>";
});

Layout:

@requirejs
@stack('requirejs-modules')

3. Page-specific module loading via @push/@stack

This maps cleanly onto Laravel's stack workflow and is the pattern you'll use every day:

@push('requirejs-modules')
<script>require(['app/dashboard']);</script>
@endpush

Global config lives in the layout; each page pushes only its entry module. Avoid per-page require.config() overrides — they cause silent path drift.

4. Build pipeline: run r.js outside Mix/Vite

Laravel Mix and Vite are ESM-first; RequireJS is AMD. Do not fight the toolchain. Keep AMD builds as a separate, explicit npm/composer script:

{ "scripts": { "build:amd": "r.js -o build.js" } }

// build.js
({
    baseUrl: "resources/js",
    name: "app/main",
    out: "public/js/app-built.js",
    paths: { jquery: "vendor/jquery" }
})

Run it in CI (or a Composer post-install script), then reference public/js/app-built.js from Blade. Generate build.js from the same PHP config if you want a single source of truth; keep it static if the config rarely changes.

5. Treat the bundle as a configuration blueprint

The highest-leverage pattern for a Laravel team is to copy the config concepts, not the code: baseUrl, paths, shim, deps, map, waitSeconds. Reproduce the bundle's Twig output with @json or json_encode in Blade. Skip the Symfony DI classes unless you are reverse-engineering how the optimizer resolves a graph.

Gotchas and Tips

• Archived and Symfony2-only. No maintainer, no security responsiveness, no modern Symfony support. Treat any code touching it as technical debt with a scheduled removal, not a platform to extend.
• No Blade/Twig parity. The bundle's Twig extension will not work in Blade. You must reproduce its output manually. Copy the emitted shape, then verify against Twig/ in the repo.
• Asset root mismatch. Symfony2 assumes web/ as the document root; Laravel uses public/. Every baseUrl and paths entry needs translating. A silent 404 on a module is almost always this.
• Composer conflicts. Adding the bundle to a Laravel app risks pulling Symfony 2.x components that collide with current Laravel constraints. If you must inspect it, clone the repo instead of requiring it.
• Shim vs. deps confusion. shim declares non-AMD globals and their exports; deps forces load order. Mixing them up produces "$ is undefined" errors that look like a RequireJS bug but are a config bug.
• Debugging a module graph. Set waitSeconds low in dev to surface unresolved paths fast. Then bisect by loading a single module ID directly (require(['app/foo'])) — most failures are a bad paths entry, not a code error.
• Optimizer output is cache-hostile. r.js writes a new bundle file each build. In production, reference a hashed/versioned filename (e.g., via mix()-style manifest) or you will ship stale AMD bundles behind CDN cache.
• Don't mix ESM and AMD in one entry. Keep Vite-built ESM and r.js-built AMD bundles in separate Blade layouts/routes. Interleaving them causes double-loading of RequireJS and unpredictable execution order.
• Extension points are useless to you. The bundle's intended extension points are Symfony DI service overrides and compiler passes — not applicable in Laravel. If you need customization, extend your own config/requirejs.php and the small Blade directive; do not fork the bundle.
• Migration signal. If a legacy Symfony2/RequireJS app is in play, isolate it, map modules to ES import(), and migrate behind a feature flag rather than porting this bundle forward.