Ux Sdc Laravel Package

Getting Started

First, calibrate the package type: tito10047/ux-sdc is a Symfony UX-style bundle, not a native Laravel package. If you're working in Laravel, verify whether the package explicitly supports Laravel before adopting it; otherwise treat it as a Symfony bundle whose component conventions you may borrow, not as a service-provider package.

Minimal steps for a Symfony host:

1. Install the new release:

   composer require tito10047/ux-sdc:^0.3
   

2. Because 0.3.0 changes the bundle name, update config/bundles.php to register the new bundle class. Check the 0.3.0 PR/changelog for the exact class name rather than guessing.
3. Search the project for the old bundle name and update any config, service definitions, or docs that reference it.
4. Clear caches:

   bin/console cache:clear
   

5. Open the README and examples first, then wire one small component into a page to confirm rendering and asset discovery.

For a Laravel developer, the first useful use case is understanding the single-directory component convention: one folder per UI component containing its template, styles, and scripts. If the package has no Laravel integration, mirror that convention with Blade resources/views/components and Vite rather than forcing bundle registration.

Implementation Patterns

Use the package as a component-first UI workflow:

• One directory per component. Keep template, CSS, JS, and metadata colocated so day-to-day changes stay local.
• Render through the package's supported template path. In Symfony, call the component from Twig templates; in Laravel, map the same idea to Blade components unless native support exists.
• Pass data explicitly. Treat props as a public API: name them clearly, keep defaults in the component, and avoid reaching into global state.
• Centralize configuration. Register component paths/namespaces once in bundle config or app config. Avoid scattering directory discovery settings across services.
• Integrate with the asset pipeline early. Confirm how component CSS/JS is discovered by Encore/Vite/Webpack. Test a production build before building many components.
• Start with design-system pieces. Buttons, cards, alerts, and page sections are safer first candidates than complex interactive components.
• Keep overrides outside vendor. If you need to customize templates or config, use documented override paths rather than editing vendor/.

Laravel-oriented pattern: if you adopt the convention rather than the bundle, create a Blade component plus a colocated asset entry, and document the mapping so Symfony-oriented examples stay understandable.

Gotchas and Tips

• 0.3.0 is a BC break. The bundle name changed. Update config/bundles.php, any YAML config keys tied to the bundle alias, service references, and deployment scripts. Search for the old bundle name before upgrading.
• Pin if migration is blocked. If you cannot update bundle registration immediately, stay on the 0.2 line and schedule the rename.
• Clear caches after upgrade. A stale container or config cache often presents as “bundle class not found” or “bundle not enabled.”
• This is pre-1.0 software. Treat minor releases as potentially breaking; read CHANGELOG.md before every upgrade.
• Don't assume Laravel conventions. A Symfony bundle will not automatically provide a Laravel service provider, Blade directives, or Laravel config publishing. Confirm support before planning Laravel use.
• Debug with Symfony tooling. Use bin/console debug:container, debug:config, and cache:clear when registration or configuration fails.
• Extension points matter more than internals. Prefer documented template overrides, component directory config, and asset configuration over subclassing vendor classes.
• Production build check. Component-colocated assets can work in dev and fail after a production asset build; verify both paths before broad adoption.