- What is vanilo/contracts and what does it actually do?
- It is a pure interface package that defines the shared PHP contracts behind Vanilo's e-commerce components, covering products, orders, customers, pricing, payments, shipping, and promotions. It contains no services, migrations, configuration, or runtime behavior. Its value is giving every Vanilo component and custom extension a common vocabulary to code against.
- How do I install vanilo/contracts with Composer?
- Run composer require vanilo/contracts, though in most Vanilo projects it arrives transitively through vanilo/framework or the component packages. There is no service provider to register and no config to publish because the package only ships interfaces. You normally add it explicitly only when building custom modules that type-hint the contracts.
- Do I need to install vanilo/contracts separately in a Laravel app?
- Usually no. Composer pulls it in automatically as a dependency of Vanilo's framework and component packages. Add it as a direct requirement if your own code imports the interfaces, so your dependency is explicit rather than relying on transitive resolution.
- Which Laravel versions does vanilo/contracts support?
- The package itself is framework-agnostic PHP interfaces, so compatibility is governed by the Vanilo release line you use rather than a standalone Laravel constraint. Check the vanilo/framework version and its Laravel support matrix, then match the contracts major that belongs to that line. Avoid mixing contract majors across vanilo/* packages.
- Can I implement my own Product model using Vanilo\Contracts\Product?
- Yes, that is the intended use: bind your code to interfaces rather than to Vanilo's concrete Eloquent models. Implement every method the interface requires, then register or resolve your class where Vanilo expects a product. Keep the implementation behind a thin adapter so future contract changes are contained.
- Does vanilo/contracts add database tables or configuration?
- No. It ships only PHP interfaces, with no migrations, service providers, config files, or runtime behavior. Any tables, models, and settings come from the concrete Vanilo component packages or your own application code. Treat this package as an API specification published to Composer.
- How do I test that my classes satisfy Vanilo contracts?
- Write a contract-conformance test suite that instantiates each custom implementation and asserts instanceof for every contract it claims to satisfy. Also assert that required methods exist and return the expected types. Because missing methods only surface when the class is loaded, these tests catch breakage before production.
- What happens to vanilo/contracts when Vanilo has a major upgrade?
- Interfaces are a public API, so adding or changing methods is a breaking change for anyone implementing them. Vanilo majors have reshuffled contracts before, so upgrading means auditing your implementations against a diff of interface definitions. Pin the exact minor, keep implementations behind adapters, and run conformance tests after each upgrade.
- Is vanilo/contracts safe to use in production?
- It cannot break at runtime because it contains no executable logic, so the risk is not runtime failure but contract churn in your own implementations. Pin the version, keep a conformance test suite, and record a fallback plan. It is MIT licensed and, being only interfaces, is straightforward to fork and vendor if maintenance stalls.
- Is there community support or alternatives to vanilo/contracts?
- The package has little standalone community because it is consumed transitively, so expect to read the source and Vanilo docs rather than find tutorials. Alternatives are writing your own domain interfaces or coding directly against concrete Vanilo models, which couples you to their implementation. Outside the Vanilo ecosystem it offers almost no value.