如何将PHP代码拆分为可复用Composer包？解决模块复用类冲突

Great questions! Let's break this down step by step, since you're dealing with two key concerns: turning your framework modules into reusable Composer packages, and avoiding class duplication headaches when sharing dependencies across your project.

First, let's get those modules out of your framework and into standalone packages that can be pulled in via Composer easily.

• Isolate your module code
  Start by extracting the module you want to reuse into a separate directory. Make sure it doesn’t rely on hardcoded framework logic unless you explicitly declare that dependency later. A clean package structure might look like this:

  your-vendor/your-module/
  ├── src/
  │   ├── Core/
  │   └── Helpers/
  ├── composer.json
  └── README.md
  

  Keep all your module’s classes inside the src/ folder—this follows standard PHP package conventions.

• Set up the composer.json for your package
  This file is the backbone of your Composer package; it tells Composer everything it needs to know. Here’s a template to adapt:

  {
      "name": "your-vendor/your-module",
      "description": "Reusable [module purpose] for my custom PHP framework",
      "type": "library",
      "license": "MIT",
      "autoload": {
          "psr-4": {
              "YourVendor\\YourModule\\": "src/"
          }
      },
      "require": {
          "php": "^7.4|^8.0",
          "your-vendor/custom-framework-core": "^1.0" // Add framework core dependency if needed
      }
  }
  

  The psr-4 rule is critical here—it maps your module’s namespace to the src/ directory, so Composer can automatically load your classes without manual require calls.

• Test locally before publishing
  If you don’t want to push to a public repo yet, you can link your local package to a test project. In your test project’s composer.json, add:

  "require": {
      "your-vendor/your-module": "dev-main"
  },
  "repositories": [
      {
          "type": "path",
          "url": "../path/to/your-module"
      }
  ]
  

  Run composer update, and Composer will symlink your local package into the project’s vendor/ folder—perfect for iterating quickly.

• Publish your package
  For public reuse: Push your package to GitHub/GitLab, then submit it to Packagist. For private use: Use a private Composer repo like Satis, GitHub Packages, or GitLab Packages. Once published, any project can pull it in with a simple composer require your-vendor/your-module.

The good news is you don’t need those messy if(class_exists()) checks—Composer’s built-in tools solve this automatically.

• Composer resolves dependencies to a single version
  When multiple packages in your project require the same RequiredPackage, Composer will analyze all version constraints and install a single version that satisfies everyone (assuming there’s no version conflict). No duplicate installs mean no duplicate class declarations.

• Always use Composer's autoloader
  In your project’s entry point (like index.php), include the autoloader once:

  require __DIR__ . '/vendor/autoload.php';
  

  This autoloader tracks every class it loads, so it will never load the same class file twice. As long as you reference classes via their full namespace (per your PSR-4 setup), Composer handles the rest—no manual require or existence checks needed.

• Stick to PSR autoload standards
  Make sure all your packages (including your framework core and reusable modules) use PSR-4 (or PSR-0, though PSR-4 is preferred) for autoloading. Avoid using raw include/require statements for class files—this bypasses Composer’s tracking and can lead to duplicate declarations.

• Legacy code workaround
  If you have old framework code that doesn’t follow PSR standards, you can add a classmap to your framework’s composer.json:

  "autoload": {
      "classmap": ["src/LegacyCode/"]
  }
  

  Run composer dump-autoload to generate the class map, and Composer will load those legacy classes safely without duplicates.

内容的提问来源于stack exchange，提问作者coolpasta