Weave Code
Common Bundle Laravel Package
space-monkeys/common-bundle
Space Monkeys Common Bundle collects reusable PHP components and shared conventions into one installable bundle, helping teams standardize common functionality and reduce duplication across applications. It provides a consistent foundation for shared services, helpers, and configuration.
Bundle with commonly used components for Symfony / Sulu CMS projects.
Frequently asked questions about Common Bundle
- Is space-monkeys/common-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle built for Sulu CMS, not a Laravel package. It ships Symfony service definitions, DI extension configuration, and shared helpers rather than Laravel service providers and config publishing. The two ecosystems solve the same problems in incompatible ways, so treat any framing of this as a Laravel dependency as an intake error to correct first.
- Can I install space-monkeys/common-bundle in a Laravel application?
- No, not directly. Laravel's package discovery and service provider model cannot register a Symfony kernel bundle, and the bundle's YAML extension config has no equivalent in Laravel's config/*.php files. If you want the logic, fork the repository, inventory the files, keep only framework-agnostic helpers, and re-express configuration as a Laravel service provider with publishable config.
- What does this bundle actually contain?
- The public description only promises shared service definitions, configuration defaults, and common helper utilities. There is no published file-level inventory, so the surface could be a handful of pure helpers or deeply Sulu-coupled services touching content resolution and admin UI extensions. Producing that inventory is the cheapest first deliverable and should happen before any estimate is committed.
- Which PHP, Symfony, and Sulu versions does it support?
- Composer version constraints are not verifiable from the outside, so supported PHP, Symfony, and Sulu ranges are unknown. That matters because the bundle will effectively pin older framework versions and become a release gate for every Sulu major, Symfony minor, and PHP bump. Check composer.json yourself and confirm whether any supported versions are still receiving security fixes.
- How do I install and register the bundle in a Symfony application?
- Install it with Composer and then register the bundle in your kernel's bundle list, which is the standard Symfony flow. From there, default services and configuration should be available, with overrides handled through the bundle's DI extension in YAML. Confirm the exact bundle class name and config alias from the repository, since the overview does not state them.
- How do I override the bundle's default configuration?
- The overview states it ships sensible defaults with extension-friendly overrides, which in Symfony means overriding values under the bundle's configuration key in your app config. Nested keys are typically merged by the DI extension, but the exact merge behaviour depends on how the extension is written. Read the extension class before relying on partial overrides in production.
- Is space-monkeys/common-bundle safe to use in production?
- There is no third-party production validation to cite: the package shows zero stars, zero dependents, and no visible issue-tracker history. That is an adoption-risk signal rather than a code-quality judgement, but it means no documented security disclosure path and a likely single-maintainer bus factor. Get license clarity, constraint clarity, and a named internal owner for the fork before it goes anywhere near production.
- What license is it under, and can I fork and modify it?
- The license is not verified in the available material, and unverified licensing is a hard gate. Without clear permission for internal redistribution and modification, you cannot legally fork, vendor, or adapt the code, which blocks the only sensible Laravel strategy. Resolve this before spending any engineering time on the package.
- How do I port the helpers from this bundle to Laravel?
- Do not attempt a direct integration. Fork and vendor the repository, classify each component as portable utility, framework-coupled, or Sulu-coupled, and keep only the portable tier. Rebuild configuration idiomatically as a Laravel service provider with publishable config and environment-driven values, and scope anything touching Sulu's content model as a separate rewrite or drop it entirely.
- What are the alternatives if I am not running Sulu?
- If your estate is Laravel, this package is a source of vetted reference logic rather than something to adopt, so the realistic alternatives are first-party helpers or a small internal package you own. If you are on Symfony, use maintained Symfony components or your own shared bundle with a documented release process. In both cases an unmaintained third-party bundle with no dependents adds release risk without adding much value.
Weaver
How can I help you explore Laravel packages today?