Boilerplate Bundle Laravel Package

Getting Started

• Treat this as a Symfony2/Twig reference implementation, not a Laravel package. Do not composer require it into a Laravel app; it has no Laravel service provider, no Blade views, and targets Symfony2 conventions.
• First look at the repository’s Resources/views directory and README. The value for a Laravel developer is the HTML5 Boilerplate-derived Twig layout, not the bundle wiring.
• Minimal Laravel use case: clone/download the repo, copy the base template structure into resources/views/layouts/app.blade.php, and convert Twig blocks to Blade sections.
• If you are actually maintaining a legacy Symfony2 app, install it there via Composer, register Oryzone\Bundle\BoilerplateBundle\OryzoneBoilerplateBundle in AppKernel, and extend its Twig templates normally.
• Start by identifying the reusable pieces: HTML5 Boilerplate head/meta setup, Modernizr/normalize includes, conditional comments, and base CSS/JS scaffolding.

Implementation Patterns

• Template porting pattern: Convert Twig {% block %} / {% extends %} / {% include %} into Blade @section / @yield / @extends / @include. Keep the HTML5 Boilerplate structure intact and replace Symfony-specific helpers as you go.
• Scaffold-once pattern: Use the bundle as a one-time scaffold for a new Laravel layout, then discard the package. Build layouts/app.blade.php, partials/head.blade.php, partials/scripts.blade.php, and a starter home.blade.php.
• Asset pipeline adaptation: The original bundle assumes Symfony/Assetic-style assets. In Laravel, replace those references with asset() / mix() / Vite helpers and move CSS/JS into resources/css and resources/js.
• Legacy Symfony integration: If you must support a Symfony2 project, extend the bundle’s Twig templates via bundle inheritance and override only the blocks you need. Keep custom templates in app/Resources/OryzoneBoilerplateBundle/views/.
• Boilerplate reference pattern: Use the repo as a checklist for HTML5 Boilerplate essentials—viewport meta, X-UA-Compatible, favicon/apple-touch-icon links, Modernizr, analytics snippet placement, and print styles—rather than as a runtime dependency.
• Day-to-day workflow: Copy template → convert Twig syntax → replace Symfony helpers → wire Laravel Mix/Vite → verify responsive/meta/asset paths → commit as project-owned Blade layout.

Gotchas and Tips

• Framework mismatch is the main gotcha: This is Symfony2 + Twig. Laravel uses Blade. Running Twig inside Laravel is possible but not worth it for a 2015 bundle with 58 stars and no recent releases.
• Abandoned/old dependencies: Last release was 2015 and Symfony2 is EOL. Installing it in a modern Laravel or Symfony app will likely create Composer conflicts and outdated frontend assets.
• Symfony helpers will break in Blade: Templates may reference asset(), path(), controller(), or Assetic tags. Replace them with Laravel’s asset(), route(), @yield, and Mix/Vite directives.
• No Laravel auto-discovery: There is no extra.laravel provider, facade, config publish, or view namespace. Any integration is manual copying, not package installation.
• Asset paths are the usual debugging culprit: After porting, check public/ paths, mix-manifest.json, and whether CSS/JS files were actually copied from the bundle. Broken Modernizr or normalize paths are common.
• HTML5 Boilerplate has moved on: The bundle pins an older boilerplate baseline. Prefer the current official HTML5 Boilerplate for new projects, or use this repo only for structural inspiration.
• Extension point is Twig bundle inheritance, not Laravel: In Symfony you override templates by convention. In Laravel, simply copy and modify the Blade files—there is no bundle override mechanism to preserve.
• License/attribution: Check the repo license and HTML5 Boilerplate attribution before shipping copied templates in a commercial Laravel app.