- Is piedweb/static-bundle a Laravel package?
- No. Despite appearing in Laravel and PHP package feeds, it is a Symfony bundle, identified by its Bundle suffix and its DependencyInjection and Resources/config conventions. There is no Laravel service provider, no publishable config, and no adapter layer. Using it in a Laravel app would mean running a parallel Symfony kernel or writing a custom bridge.
- Can I just run composer require piedweb/static-bundle in a Laravel project?
- You can install it, but Composer installing code is not the same as the framework being able to use it. Laravel will not discover or register the bundle, and none of its services will be wired into the container. Treat a successful install as meaningless until you have proven the bundle boots under a Symfony kernel.
- Is piedweb/static-bundle actively maintained?
- No. The repository is archived, which makes it read-only: no security patches, no PHP version bumps, and no framework compatibility updates. It also has roughly one star, zero dependents, and no issue activity, so there is no community footprint validating real-world use. Adoption is effectively a fork-and-own decision from day one.
- What does piedweb/static-bundle actually produce, static HTML or a cache warm?
- Per its description, it is a static site generation layer for the Pied Web CMS that exports pages as pre-rendered HTML files. Whether a given route is fully prerendered, partially cached, or skipped depends on the bundle's configuration and the CMS content model. Confirm the exact output in a throwaway app before assuming it matches your CDN or static host delivery model.
- Does piedweb/static-bundle support current Symfony LTS and PHP 8 versions?
- That is unknown and not verifiable from the package metadata alone. Because the repository is archived, any declared framework constraints are almost certainly behind the current Symfony LTS. Audit the PHP requirement, Twig version, and Symfony component constraints directly in composer.json before you scope any work, and budget a spike to confirm the bundle even boots on your target kernel.
- How do I install and configure piedweb/static-bundle?
- There is no documented, reusable integration path here, and the upstream project does not describe one. The realistic approach is to vendor the source into your monorepo via a path or VCS Composer repository, pin the fork, and register the bundle in a Symfony kernel yourself. Expect to audit the service definitions against your Symfony version and add the CI pipeline the original never had.
- What are the production risks of using an archived static site generator?
- The main risk is a frozen dependency: the moment your host PHP or Symfony version moves, nothing upstream will fix it. Combined with zero dependents, there is no evidence anyone has run this in production recently, so you would be the first to discover breakages. The MIT license and small codebase are the only real mitigants, since they let you fork and patch internally.
- Does static generation with this bundle break dynamic or personalized pages?
- Static generation presupposes a content model that tolerates prerendering, so per-request personalization, live inventory, and session-dependent output are inherently unsupported. If your product depends on any of those, static site generation is the wrong delivery model regardless of package quality. Decide the delivery model first, then choose a tool that fits it.
- What are the alternatives to piedweb/static-bundle for Laravel or Symfony apps?
- For Laravel, the well-trodden path is generating static output directly against the framework's own routing and Blade or Twig templates, typically via an Artisan command that writes files to a static host. That avoids an unmaintained third-party dependency and keeps the output portable as plain HTML. For Symfony, evaluate maintained SSG options or a small in-house prerender command over an archived CMS-coupled bundle.
- How much work is it to fork and maintain piedweb/static-bundle?
- It is a multi-week adoption effort disguised as a dependency install, not a quick fork. Plan for a two-day spike first: install the fork in a throwaway Symfony app, boot the kernel, attempt a prerender, and document exactly which Pied Web CMS assumptions break. If the spike fails, stop and build static generation against your own routes and templates instead, because the exit cost of an unmaintainable fork is high if the output is locked into CMS-specific conventions.