Weave Code
Connections For Laravel Laravel Package
roundly-consulting/connections-for-laravel
Connections for Laravel provides a clean, Eloquent-friendly way to store and manage connections to external services, including credentials and provider details. Bind accounts, handle tokens, and keep everything organized in one place.
Many-to-many connections between Eloquent models with permissions and expirations.
Frequently asked questions about Connections For Laravel
- What is roundly-consulting/connections-for-laravel used for?
- It stores many-to-many connections between Eloquent models and attaches per-connection data such as permissions and expiration timestamps, so a relationship carries more than a bare pivot row. It can also hold credential and provider details for connections to external services, keeping tokens, account bindings, and provider metadata in one place. If your domain question is who is linked to what, with which rights, and until when, this package is a natural fit.
- How do I install connections-for-laravel in a Laravel application?
- Install it with Composer, pinning the fixed release explicitly: composer require roundly-consulting/connections-for-laravel:^1.1.2. Laravel service-provider auto-discovery should register the package without manual edits to config/app.php. Then run php artisan vendor:publish to pull out the configuration file and any migration stubs, and run php artisan migrate if tables are shipped. Pinning ^1.1.2 prevents an environment from resolving to a pre-fix patch.
- Which Laravel and PHP versions does connections-for-laravel support?
- The available package context does not state a supported Laravel or PHP matrix, so check the require constraints in the package composer.json against your framework version before adopting it. The package assumes a conventional Composer-managed Laravel application on a PHP 8.x runtime. Do not assume support for non-Laravel runtimes or for framework versions outside those declared constraints.
- Does the package ship database migrations and tables?
- The package persists connections through Eloquent models, so expect publishable migrations that create the connections table and its columns for permissions, expiration, and provider or credential details. Run vendor:publish and inspect the published migration files and schema before migrating, so you know exactly which columns and indexes you are adding. If a given release is stateless for your use case, the publish step will show that too, which is why checking the published assets matters more than assuming.
- Can I swap the package's model for my own Eloquent model?
- Yes. Host-side model substitution is a supported idiom, and release 1.1.2 specifically fixed factories so they build the configured model when a host swaps it. Rebind the model through the package configuration or the service container rather than editing vendor code, and make sure your replacement model satisfies the contract the package expects, such as the right base class, table, casts, and relationships. After changing the binding, re-run php artisan config:cache so the swap actually takes effect.
- Why should I upgrade to version 1.1.2 even though it looks like a patch release?
- Before 1.1.2, factories built fixtures from the package base model even when a host had swapped in its own model, so test suites were exercising a different class than production. That is a correctness-of-confidence bug rather than an outage-class bug, but it means assertions could pass against the wrong model. The fix is contained, with no stated breaking changes or new configuration surface, and upgrading is a lockfile bump for existing 1.1.x installs. Any test that only passed on a pre-1.1.2 version should be reviewed as previously invalid.
- How do I test that the model swap is actually working?
- Create an instance through the package factory in a test and assert that it is an instance of your swapped class rather than the package base model. Cover the pivot behaviour too, including permission and expiration fields, so the swap is verified end to end. Then run the full application test suite with factories pointed at the swapped model and treat any newly failing test as a signal that it was previously asserting against the wrong class.
- Does connections-for-laravel work with Laravel config caching?
- It can, but a model bound through configuration will not take effect until the cached config is rebuilt. After deployment or after changing the model binding, run php artisan config:cache and verify in staging that model resolution returns the swapped class. This is an easy production gotcha: the code is correct, but a stale config cache keeps serving the old binding.
- How do permissions and expirations on a connection work?
- Permissions and expiration values are stored on the connection record, so each link between two models can carry its own rights and its own expiry timestamp. Your application remains responsible for enforcing those values through policies, gates, or query scopes that filter out expired connections. The package handles storage, relations, and the Eloquent surface; business authorization rules still belong in your domain code.
- Is connections-for-laravel production-ready and actively maintained?
- The architecture is standard Laravel, with a service provider, publishable configuration, factories, and support for host-side model substitution, and the 1.1.2 release is a contained patch with no stated breaking changes, so technical risk is low. Maintainer health, licence, CI coverage, and release cadence are not documented in the available context, so review the GitHub repository and Packagist page before depending on it. If you only need a plain many-to-many relationship with no permissions or expiry metadata, native belongsToMany with a custom pivot model may be simpler; adopt this package when you want the built-in permission, expiration, and credential handling.
Weaver
How can I help you explore Laravel packages today?