Third-party libraries (on any host)

Your module needs the AWS SDK for S3, or Stripe for billing. On a Composer box that's trivial. On the shared hosts Tiger targets — GoDaddy, BlueHost, cPanel — there's no Composer, often no shell, and those SDKs drag a knot of their own dependencies (Guzzle, PSR-7, promises…). Tiger provisions them anyway.

The idea: resolve off-box, ship the result

Resolving a dependency graph is genuinely hard — it's why Composer exists — so Tiger never does it on the customer's host. Resolution runs once, off-box (our CI), producing a pre-resolved bundle: the library plus every dependency plus an autoloader, frozen into one checksummed archive. The host downloads one file and unpacks it. No resolution, no dependency hell.

Three tiers, automatic

When a module needs a library, Tiger_Vendor picks the best path the host allows and fails closed:

Tier When Handles deps?
Composer the host has a usable Composer (binary + exec + writable vendor/) yes — Composer
Pre-built bundle no Composer; the lib is in Tiger's vendored-bundle registry yes — resolved in CI
Raw tarball no Composer; the lib has no PHP deps (a single-file lib) nothing to resolve

You don't choose the tier — the environment does.

Declare it in module.json

"dependencies": {
  "php": [
    { "name": "aws/aws-sdk-php", "constraint": "^3", "optional": false }
  ],
  "asset": [
    { "name": "swagger-ui", "tarball": "…/swagger-ui-dist.tgz",
      "include": ["swagger-ui.css", "swagger-ui-bundle.js"],
      "target": "assets/vendor/swagger-ui", "optional": true }
  ]
}
  • php libraries land in a shared vendor-libs/ store and are autoloaded for every module — one copy, deduped, one version per install (a genuine version conflict between two modules is reported, never silently double-installed).
  • asset dependencies (front-end JS/CSS) are fetched into the module's own assets/.
  • optional: true means a failed fetch degrades rather than blocking install — the module still installs; the feature that needed the lib just isn't available.

On install, Tiger provisions each declared dependency and reports the outcome per item.

What you don't do

You never commit a copy of the AWS SDK into your module, and you never run Composer on the customer's box. Declare the dependency; the platform makes it present and findable — the same on a Composer server and a no-shell cPanel account.

See also