Assets Laravel Package

Product Decisions This Supports

• Build vs. buy / extract vs. adopt: v0.1.0 turns Pollora’s asset layer into a standalone package, so teams can adopt the same asset container, enqueuer, and Vite resolution model without committing to Laravel. This is a signal that the asset subsystem is being positioned as reusable infrastructure rather than framework-only glue.
• Frontend tooling roadmap: The package supports a Vite-first WordPress strategy. NativeViteManager reads the manifest and hot file directly and is described as returning the same answers as the framework resolver, which reduces the risk of divergent frontend build behavior across Laravel and non-Laravel WordPress projects.
• Portfolio and platform reuse: The ViteManagerFactory, RuntimeContext, and PublicPath contracts let teams bind asset behavior to different environments. That is a useful architectural seam for supporting classic themes, plugins, and Bedrock sites with one asset model.
• Feature scope for WordPress products: Asset::add()->container()->useVite()->toFrontend() and Asset::addContainer() give PMs a concrete API surface to evaluate for theme/plugin asset registration, enqueueing, and Vite integration.
• Migration and consolidation decisions: Because class names are unchanged from the framework, existing Pollora users can assess whether the standalone package reduces coupling or creates duplication. New non-Laravel WordPress projects can pilot the package without adopting the full framework.

When to Consider This Package

Consider it when:

• You are building a WordPress classic theme, plugin, or Bedrock site and want structured asset containers, enqueueing, and Vite manifest/hot-file resolution without Laravel.
• You already use Pollora or @pollora/vite-config and want the asset layer available outside the full framework.
• You need a small, explicit asset abstraction with environment-binding contracts rather than a full framework dependency.
• You are standardizing Vite across WordPress properties and want the same resolver behavior in Laravel and non-Laravel contexts.
• You are willing to treat v0.1.0 as an early-stage package and can validate API stability, documentation, and upgrade paths before broad adoption.

Look elsewhere when:

• You need a mature, widely adopted asset package with long-term support guarantees; v0.1.0 is a first release.
• Your project already uses Laravel and the framework’s built-in asset layer is sufficient; adopting the standalone package may add unnecessary surface area.
• You need broad CMS/framework support beyond WordPress or non-Vite build pipelines.
• You require documented plugin ecosystems, community examples, or stable contracts; the three contracts are promising but currently imply implementation work for each environment.
• You cannot absorb potential API churn during early releases.

How to Pitch It (Stakeholders)

For executives: This release extracts Pollora’s asset management and Vite resolver into a standalone package, so we can reuse the same frontend asset model on WordPress themes, plugins, and Bedrock sites without taking on Laravel. That reduces platform coupling and supports a consistent Vite-based frontend strategy. The caveat is maturity: v0.1.0 is a first release, so this is best treated as a pilot or strategic option rather than a default standard.

For engineering: The package preserves the framework’s class names and introduces clean environment contracts (ViteManagerFactory, RuntimeContext, PublicPath). NativeViteManager provides manifest and hot-file resolution outside Laravel, and the Pollora\Asset\Asset facade supports classic themes, plugins, and Bedrock with declared containers. Evaluate API stability, documentation, and contract implementations before production adoption; the architecture is sound, but the release is early.