- How do I install smorken/model in a Laravel application?
- Add a repositories entry to composer.json pointing at the Bitbucket git URL, run composer require smorken/model, and register the service provider only if the package actually ships one. Because the package is not distributed through Packagist, every developer machine, CI runner, and container build needs credentials for that private repository. The mechanical setup takes minutes; the credential plumbing is the real work.
- Is smorken/model available on Packagist, and why does composer require fail?
- No. The package is hosted on Bitbucket with no Packagist entry, so a bare composer require smorken/model will not resolve on its own. You must declare the VCS repository in composer.json first, after which Composer pins to whichever branch or commit ref you specify. That also means no version constraint resolution, no composer audit coverage, and no security advisory feed for the package.
- Which Laravel and PHP versions does smorken/model support?
- The available metadata does not state supported Laravel or PHP versions. Check the package's composer.json for explicit illuminate/* constraints before assuming compatibility, since a bare or wildcard constraint is a warning sign. Base model packages tend to touch Eloquent internals that shift between majors, such as casts, attribute mutators, and the $dates deprecation, so verify against your exact target versions on a throwaway branch first.
- What does smorken/model actually include?
- The package is described only as extended models for Laravel, which points to a lightweight base model plus reusable Eloquent traits or helpers. The exact behavior set is not documented in the provided metadata, so treat it as unaudited until you read the source. Note whether it merely adds convenience such as UUIDs, slugs, casts, or soft-delete helpers, or whether it overrides query building, hydration, or serialization, because the blast radius of those two cases is very different.
- Is smorken/model safe to use in production?
- Only after an audit and preferably a fork. It is a single-maintainer, near-zero-adoption dependency sitting underneath your entire persistence layer, so a defect is global rather than contained to one feature. There is no visible evidence of a test suite, license clarity, or a tagged release feed. Treat adoption as a code-review obligation, not a one-line composer install.
- Can I use smorken/model if my app already has a base model?
- Not cleanly, because PHP has no multiple inheritance and adopting a vendor base model means refactoring your existing base class to extend it. That pushes third-party code beneath all your current shared behavior, which is the layer you least want an unmaintained dependency at. If your base class is small, consider extracting its behavior into traits so additions stay removable.
- What license does smorken/model use?
- Check the repository for a LICENSE file before merging any code, since Bitbucket projects frequently ship without one. An unlicensed dependency inside a commercial codebase is a legal exposure that should be resolved with the maintainer in writing before adoption. No Packagist presence also means there is no security advisory channel covering this package.
- How should I install smorken/model in CI and production deploys?
- Do not point production at the Bitbucket repository directly. Fork the source into your own VCS, or vendor it into a packages/ path repository, and publish it through Satis, Private Packagist, or a monorepo so you install from infrastructure you control. That removes per-machine deploy keys, gives you tagged releases and version constraints, and lets you patch the code yourself if it is abandoned.
- How do I test smorken/model before adopting it?
- Write characterization tests against the behaviors you actually rely on: model creation, casting, serialization to array and JSON, and soft deletes. Run them on your target Laravel and PHP versions, since there is no published test suite to lean on and you are establishing the baseline yourself. Keep those tests in your own repository so any upstream or fork update surfaces regressions immediately.
- What are the alternatives to smorken/model, and how do I migrate off it?
- For specific behaviors, first-party Laravel features plus well-adopted packages such as spatie/laravel-sluggable or laravel/helpers often cover the same ground with maintained releases and clear licensing. If you do adopt smorken/model, keep its behavior additive through traits you can remove rather than logic baked into schema or serialization. Plan the exit before the install, so migration off it is a delete rather than a data migration.