Autoloader voor eigen classes: Apart of via Composer?

[Aar]

Momenteel ben ik lekker bezig met mijn CMS-project, en ik gebruik momenteel een hoop classes, en ook diverse classes en packages via Composer. Voor alle Composer-packages gebruik ik de standaard Autoloader die Composer aanmaakt, maar mijn eigen classes gebruiken nog geen autoloader. Nu wil ik deze wel gebruiken....

Nu ben ik benieuwd wat jullie gebruiken of adviseren? Een aparte Autoloader voor je eigen classes, interfaces etc.., of ook deze afhankelijk maken van de Composer autoloader. De weg om alles via Composer te doen klinkt verleidelijk, en het meest logisch, maar ik wil niet straks tegen drempels aanlopen.

Wat is jullie advies?

Tevens heb ik dit op PHPhulp gevraagd.

 

[bron]

Composer gebruik ik niet. Bijvoorbeeld bij PHPMailer vind ik de inhoud van autoloader door even te googelen, of ik vraag het aan chatgpt/copilot

 

[Aar]

@bron Mag ik weten waarom je geen Composer gebruikt? het maakt het wel makkelijker om packages van Packagist (en dus composer) in je source te integreren en afhankelijke pakketten te beheren.

 

[bron]

Mag ik weten waarom je geen Composer gebruikt?

Het zijn kleine tools die ik schrijf, geen applicaties want daar zijn anderen beter in.

 

[Aar]

Ik ga nog eens met beide manieren experimenteren. Geheel via Composer kan, en volgens een lid op PHPhulp zou een wijziging aan de classes prima zonder 'composer dump-autoload' worden ingeladen. Des te beter.

En anders schrijf ik een eigen autoloader.

 

[Gouwepeer]

Hoe loopt jouw project @Aar? Uit interesse heb ik jouw vraag aan ChatGPT voorgelegd, misschien heb jij hier iets aan:

Mijn advies: gebruik óók voor je eigen code de Composer-autoloader (PSR-4). Dat is precies waar Composer voor bedoeld is, en je loopt er in de praktijk juist mínder drempels mee tegenaan dan met een “eigen” autoloader.

Waarom Composer voor je eigen classes (bijna altijd) de beste keuze is

• Eén autoload-systeem voor alles (vendors + eigen code) → minder complexiteit, minder edge-cases.
• Standaard in de PHP-wereld: vrijwel elke moderne lib/framework/tooling verwacht Composer/PSR-4.
• Schaalbaar: namespaces, mappenstructuur, tests, CLI-tools, refactors… werkt allemaal lekker.
• Makkelijk te debuggen: vendor/autoload.php is je single source of truth.
• Tooling sluit aan: IDE’s, static analysis (PHPStan/Psalm), PHPUnit, etc.

Hoe je dat doet (PSR-4)
Stel je hebt dit:

• src/ voor je CMS-code
• namespace MyCms\

Dan in je composer.json:

{
  "autoload": {
    "psr-4": {
      "MyCms\\": "src/"
    }
  }
}

Daarna:

composer dump-autoload

En in je entrypoint (bijv. public/index.php of bootstrap.php):

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

Vanaf dan: geen handmatige require meer voor classes binnen MyCms\....

Wanneer een “aparte autoloader” wél zin kan hebben
Heel zelden, bijvoorbeeld:

• Je maakt een project dat zonder Composer moet kunnen draaien (bijv. shared hosting zonder CLI, of distributie als “zip” zonder vendor).
• Je bouwt een plugin-systeem dat dynamisch code van derden laadt buiten Composer om.
• Je wil legacy code stap-voor-stap migreren en tijdelijk een fallback houden.

Maar zelfs dan kun je meestal nog steeds Composer gebruiken en eventueel daarnaast een mini-loader voor plugins toevoegen.

Praktische tips (drempels voorkomen)

• Houd je eigen code in src/ en niet in vendor/.
• Gebruik 1 top-level namespace voor je project (VendorName\ProjectName\), bijv. Gouwepeer\Cms\.
• Heb je “scripts” of helpers zonder class? Zet die dan onder:
  • "autoload": { "files": ["src/helpers.php"] }
    Maar: liever functies minimaliseren en naar classes/services toe werken.
• Voor tests:

"autoload-dev": {
  "psr-4": {
    "MyCms\\Tests\\": "tests/"
  }
}