Weave Code
Thompson Theme Bundle Laravel Package
integrated/thompson-theme-bundle
integrated/thompson-theme-bundle is a Laravel package that bundles the Thompson theme into reusable Blade views, assets, and configuration, making it easy to add a consistent frontend theme to your application with minimal setup.
Integrated Thompson Theme Bundle
Frequently asked questions about Thompson Theme Bundle
- How do I install the Thompson Theme Bundle in a Laravel application?
- Require it with Composer as integrated/thompson-theme-bundle, then publish the config file and asset stubs so the theme can be configured per environment. The service provider is auto-discovered on Laravel 10 and above, so no manual registration is normally needed. Because the package lives in a private Bitbucket repository, Composer needs valid credentials before the require step will succeed.
- Why does composer require fail with a 404 or authentication error for this package?
- The repository is a private Bitbucket project under an eactive workspace, so anonymous Composer installs cannot resolve it. You need scoped read access via an SSH deploy key or a Bitbucket app password, configured in auth.json locally and as secrets in every CI runner and container build. Treat credential distribution as a separate workstream, since it is the item most likely to delay the first install.
- Which Laravel and PHP versions does the Thompson Theme Bundle support?
- Check the Illuminate and PHP constraints declared in the package composer.json before adding it to any host application. The bundle targets Laravel 10+ with an auto-discovered service provider, but the exact ranges should be compared against each app lockfile. Because there are no advertised tags, Composer may resolve to a dev branch, so verify what version constraint you are actually installing.
- How do I publish the theme config and asset stubs?
- Use vendor:publish with the tags the package registers to copy the config file and front-end assets into your application. Review each publish path before running it, because vendor:publish can write into public/ or application view directories and silently overwrite assets you have already customised. Run the publish step in a clean branch first so any collisions show up in a diff rather than in production.
- Can the package's view namespace clash with my existing Blade views?
- The bundle registers a dedicated view namespace for its layouts, partials, and Blade components, which keeps theme views separate from your application views. Namespace precedence failures are quiet rather than loud, so an incorrect reference can render the wrong partial without throwing an error. Check that the namespace and any publish tags do not claim names your application already uses, and smoke test the rendered pages after install.
- Does the Thompson Theme Bundle work with both Vite and Laravel Mix?
- The package is described as compatible with both build tools, which lets it serve a mixed portfolio of Laravel apps at different front-end generations. In practice, confirm whether the Blade layouts call the mix() or vite() helper and that the matching manifest or hot file exists in each host application. Getting this wrong typically shows up as missing asset URLs or a Vite manifest not found exception.
- What Artisan commands does the package provide for switching themes?
- The bundle ships Artisan commands to scaffold a theme and switch between registered presets without editing core application code. Presets and per-environment overrides are declared in the single published config file, which keeps styling consistent across projects and environments. List the available commands after installation to confirm the exact signatures before scripting them into deployments.
- Should I use dev-main in production when there are no tagged releases?
- Avoid it. With no advertised tags, Composer will likely resolve to a mutable dev branch, which breaks build reproducibility and change control. The safer policy is to reference a specific commit SHA or a tag if one can be obtained from the eactive maintainers, and to enforce that rule in composer.lock. Ask the owning team for a tagged release as an explicit deliverable.
- Is this theme bundle safe to ship on a client-branded or revenue-facing site?
- Technically the risk is contained, because the package touches presentation only and has no data-model, auth, or domain-logic surface, so it can be removed or forked without rewriting business logic. The open questions are organisational and legal: there is no public tracker or changelog, stewardship sits with a single team, and the licence and usage rights for the bundled theme assets and fonts need written confirmation before client use. Get those confirmations before committing it to a branded release.
- How does this compare to copying the Blade views directly into my application?
- Vendoring the theme views and assets into your app removes the private Composer credential requirement and any branch-pinning risk, but you lose the upstream update path and must merge future theme changes by hand. Keeping it as a Composer dependency gives you a cleaner separation and easier swapping of presets, at the cost of supply-chain and access management. A short timeboxed spike in one application, with a static review of composer.json, service providers, and publish tags, is the cheapest way to decide which fits your portfolio.
Weaver
How can I help you explore Laravel packages today?