Publishing Your SDK to Packagist

You have a working SDK from lesson 3.14. Now make it installable globally with composer require yourvendor/catalog108-sdk. The process is short, 30 minutes from "private folder" to "live on Packagist."

Step 1, push to GitHub

Create a public GitHub repo named after the package (e.g. yourvendor/catalog108-sdk).

cd catalog108-sdk
git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin git@github.com:yourvendor/catalog108-sdk.git
git push -u origin main

Confirm the repo on GitHub shows your composer.json, src/, README.md. Public repo is required for free Packagist hosting.

Step 2, sanity-check composer.json

Two fields Packagist cares about strongly:

{
  "name": "yourvendor/catalog108-sdk",  // matches your intended Packagist URL
  "description": "Unofficial PHP SDK for...", // shown on the Packagist page
  "type": "library",
  "license": "MIT",  // SPDX-format license identifier
  "keywords": ["scraping", "catalog108", "api", "sdk"],
  "homepage": "https://github.com/yourvendor/catalog108-sdk",
  "support": {
  "issues": "https://github.com/yourvendor/catalog108-sdk/issues",
  "source": "https://github.com/yourvendor/catalog108-sdk"
  }
}

Validate locally:

composer validate

Fix any warnings before submission.

Step 3, register on Packagist

1. Sign up at https://packagist.org with the same GitHub account.
2. Click Submit Package.
3. Paste the GitHub repo URL: https://github.com/yourvendor/catalog108-sdk.
4. Packagist reads your composer.json and confirms the vendor/package name.
5. Click Check → Submit.

The package is live. URL: https://packagist.org/packages/yourvendor/catalog108-sdk.

Step 4, set up the auto-update webhook

Out of the box, Packagist updates your package by polling. Better: a GitHub webhook that notifies Packagist instantly on every push.

1. On Packagist: visit your package page → Settings → copy the API URL with your API token.
2. On GitHub: repo → Settings → Webhooks → Add webhook.
3. Payload URL: paste the Packagist URL.
4. Content type: application/json.
5. Trigger: "Just the push event."
6. Save.

Now every git push to your repo wakes Packagist within seconds.

Step 5, tag your first release

A package without tags is treated as dev-main only. Consumers can install it with "dev-main", but Composer prefers stable tags.

git tag -a v1.0.0 -m "Initial public release"
git push origin v1.0.0

Within ~30 seconds Packagist surfaces v1.0.0 on the package page. Now anyone can:

composer require yourvendor/catalog108-sdk:^1.0

Verifying the install works

Spin up a throwaway directory:

mkdir /tmp/sdk-test && cd /tmp/sdk-test
composer init -n --name=test/test --require=yourvendor/catalog108-sdk:^1.0
cat > test.php <<'PHP'
<?php
require 'vendor/autoload.php';
$client = new YourVendor\Catalog108\Catalog108Client();
$data = $client->products(1, 3);
print_r($data['products']);
PHP
php test.php

You should see three Catalog108 products. The SDK is live and consumable.

Releasing future versions

The release workflow becomes:

1. Develop on main.
2. Update CHANGELOG.md (Keep a Changelog format helps).
3. Decide the bump: patch / minor / major.
4. Tag and push:

git tag -a v1.1.0 -m "Add iterProducts() generator"
git push origin v1.1.0

5. Packagist picks up the new tag.

Bonus: a basic CHANGELOG.md

# Changelog

## [1.1.0] - 2025-08-12
### Added
- `iterProducts()` generator for paginated traversal.
### Fixed
- Retry middleware now respects `Retry-After: <date>` format.

## [1.0.0] - 2025-07-30
### Added
- Initial public release.
- Methods: `login`, `me`, `products`, `product`, `reviews`.

Maintenance considerations

• Respond to issues. A package that's silent for six months gets distrusted.
• Mark abandoned cleanly. If you stop maintaining, add "abandoned": "alternative-vendor/alt-package" to composer.json so Composer warns consumers.
• Track PHP version EOLs. When PHP 8.1 reaches EOL, bump the minimum and major-version.
• Run CI on PRs. GitHub Actions running composer test on every push catches regressions.

A minimal GitHub Actions workflow:

# .github/workflows/test.yml
name: tests
on: [push, pull_request]
jobs:
  test:
  runs-on: ubuntu-latest
  strategy:
  matrix:
  php: ['8.1', '8.2', '8.3']
  steps:
  - uses: actions/checkout@v4
  - uses: shivammathur/setup-php@v2
  with: { php-version: '${{ matrix.php }}' }
  - run: composer install
  - run: composer test

Private Packagist

For internal-only SDKs, use:

• GitHub-based, your repo can be private; Composer can install via a vcs repository entry in the consumer's composer.json.
• Packagist.com (paid), full Packagist features for private packages.
• Satis (self-hosted), generate a static Composer repo from a list of git URLs.

The pattern is the same; only the registry is different.

Hands-on lab

No specific Catalog108 lab, the lab is the publishing process itself. Follow the five steps for the SDK you built in lesson 3.14. Submit it to Packagist (use a temporary or playground vendor name if you don't want to commit to one yet). Then in a fresh project, run composer require yourvendor/catalog108-sdk:^1.0 and use the SDK. You've shipped a real package.