Weave Code
Library Laravel Package
integrated/library
Integrated Library is a Laravel/PHP package that provides a clean, reusable foundation for integrating third-party libraries into your application, with simple configuration, service provider bindings, and framework-friendly APIs that speed up development.
Integrated Library
Frequently asked questions about Library
- How do I install integrated/library if it isn't on Packagist?
- Because the package is hosted on Bitbucket and not published to Packagist, add it to the repositories section of composer.json as a type vcs entry pointing at the repository URL, then require integrated/library. Composer will resolve a branch such as dev-master unless the maintainers tag releases. Pin a specific commit or tag in composer.lock and commit the lock file so every environment installs identical code.
- Do I need Bitbucket credentials to install the package in CI?
- Yes. A private Bitbucket repository requires read access, so each developer machine and CI runner needs an SSH key or app password with repository read scope. Store the credential as a CI secret and plan for rotation. Treat this as a permanent onboarding and operational step rather than a one-time setup.
- Which Laravel and PHP versions does integrated/library support?
- The repository metadata does not publish a compatibility matrix, so read the require block of composer.json for its illuminate/* and php constraints before adopting. Tight Laravel version pins become upgrade blockers at the next major release, so check the constraints against the version you run. If the constraints look narrow or are missing, budget time for a short compatibility spike.
- How do I publish integrated/library's config file?
- Register the package service provider, then run php artisan vendor:publish with the package's publish tag to copy the config file into config/. Confirm the exact tag name in the service provider or README, since publish tags vary between packages. Commit the published config and keep environment-specific values such as credentials in .env rather than in the file itself.
- How do the service container bindings and facades work?
- The package registers bindings in Laravel's service container and exposes facades for convenient access to integrations. Prefer constructor injection of the underlying binding or contract in application code so the dependency stays explicit and easy to swap. Keep facade usage at the edges of your code rather than deep inside domain logic, which limits how expensive replacement becomes later.
- How do I mock an integration in my tests?
- The package ships test helpers intended for mocking integrations, which usually means swapping the container binding for a fake during test setup. Bind your fake in setUp or in a shared base test case, and assert on the calls your code makes rather than on real network traffic. Read how the helper resolves bindings, then wrap it in a small test utility of your own so a future package change only touches one place.
- Can I use integrated/library in a non-Laravel PHP project?
- The core is described as framework-agnostic, so the integration logic should be usable outside Laravel. In practice the service provider, facade, and config publishing layers are Laravel-specific, and you would wire the core classes manually in a plain PHP project. Check that the core namespace does not depend on illuminate/support or other framework classes before relying on this.
- What license is integrated/library released under?
- No license is visible in the available repository metadata, which is a blocking gap rather than a minor detail. A private repository does not by itself grant rights to use, modify, or redistribute the code in distributed or open-source artifacts. Get written clarification from the maintainers or your legal team before the package enters your dependency graph.
- Will the package's migrations collide with my existing schema?
- The package advertises migration-friendly assets, so it may ship migrations that publish into your application. Published migrations become your schema to own and defend, including rollback behaviour and table naming collisions. Run every published migration against a throwaway database first, and consider wrapping the package behind your own boundary if it owns tables you would otherwise control.
- How do I upgrade the package safely without Packagist version tags?
- Without Packagist releases there is no version contract, so Composer may resolve to dev-master. Pin an exact tag or commit SHA in composer.json, commit the lock file, and treat each upgrade as a reviewed change with a named owner and a date. Run the upgrade on a branch and diff config keys, migrations, and container bindings before merging.
Weaver
How can I help you explore Laravel packages today?