Weave Code
Core Bundle Laravel Package
smartbooster/core-bundle
SmartBooster Core Bundle is a Laravel/PHP package offering shared core services, configuration, and integration utilities for SmartBooster applications, helping developers bootstrap features consistently and reduce boilerplate across projects.
Bundle grouping all vendor, generic utils and services that we use on each project
Frequently asked questions about Core Bundle
- What is smartbooster/core-bundle used for?
- smartbooster/core-bundle is the shared foundation for SmartBooster PHP packages. It centralizes common configuration, service registration, reusable base classes and helpers, and integration utilities so companion packages stay consistent and lightweight. Laravel/PHP teams use it to bootstrap SmartBooster features with less boilerplate.
- How do I install smartbooster/core-bundle in a Laravel app?
- Install it with Composer using composer require smartbooster/core-bundle, then follow the package's Laravel service-provider and configuration publishing steps from the README. Because it is the shared core for SmartBooster packages, install it before or alongside the companion packages that depend on it. Confirm the package's supported Laravel/PHP constraints in its composer.json before adding it to an existing application.
- Which Laravel and PHP versions does smartbooster/core-bundle support?
- The provided context does not list exact Laravel or PHP version constraints, so check the package's composer.json and release notes before upgrading. Compatibility checks should also cover queue/event interactions and database transaction behavior when using archive and history features. Treat the supported framework and PHP matrix as part of your upgrade validation.
- How is configuration handled in smartbooster/core-bundle?
- Configuration is centralized with sensible defaults so SmartBooster components share one registration and setup path. In Laravel, review any publishable config files and service-provider registration after installation. For the v1.19.0 archive behavior, entity-level resetOnArchive settings become part of your configuration and data-retention policy.
- Can I extend SmartBooster Core Bundle with custom modules or services?
- Yes. The package is described as extensible for custom modules, with reusable base classes, helpers, and unified service registration. You can register your own services and extend SmartBooster functionality without duplicating core boilerplate. Keep custom archive implementations in mind, because the TPM assessment warns they may bypass the history-reset behavior.
- What changed in smartbooster/core-bundle v1.19.0?
- Version 1.19.0 adds automatic history reset when an entity is archived, plus an entity-level resetOnArchive override for exceptions. This is a behavior-changing default rather than an opt-in-only feature, so existing archive flows may start resetting history after upgrade. Teams should inventory archive entry points and define retention policy before deploying.
- How do I disable or override history reset for a specific entity?
- Use the entity-level resetOnArchive override for entities that must preserve history, and apply those overrides immediately after upgrading if they cannot be introduced beforehand. The context notes that reset can be disabled per entity; it does not confirm a documented global disable switch, so verify the package contract and test coverage. Document each override alongside your retention policy.
- What exactly does history reset do, and is it reversible?
- The provided context does not confirm whether reset deletes, truncates, soft-deletes, or detaches history, or whether it runs transactionally and can be reversed. Those details must be verified in the package implementation, tests, and release notes before relying on the new default. Until confirmed, treat archive-triggered reset as potentially destructive and irreversible.
- Is automatic history reset on archive a production data-loss or compliance risk?
- Yes. The TPM assessment flags unintended history loss as the primary risk because archiving now performs a destructive or irreversible history action unless overridden. That is a data-retention and auditability concern, not just a package upgrade. Monitor archive-triggered resets, keep backups or retention controls, and review bulk, admin, and API archive paths.
- How should I test and monitor archive and history-reset behavior after upgrading?
- Start in a non-production environment: inventory archivable entities and archive paths, apply resetOnArchive overrides, and run regression tests for archive, restore, and history reads. After deployment, monitor archive jobs and database pressure, and alert on archive-triggered resets. Plan rollback because reverting the package may not restore reset history; maintenance includes per-entity reset policy and documentation.
Weaver
How can I help you explore Laravel packages today?