Replace per-extension composer install with unified autoloader

[cicalese]

Summary

• Skip per-extension composer install in extensions-skins.php; log a message instead
• After the main extension/skin loop, create build-time symlinks in extensions//skins/ → canasta-extensions//canasta-skins/ so composer.json references work at build time
• Write composer.local.json with specific entries for bundled extensions that need composer (identified by "composer update" in their additional steps)
• Run a single root-level composer update to produce a unified vendor/autoload.php
• Save a hash of all contributing composer.json files to .composer-deps-hash
• Save composer.local.json to $MW_ORIGIN_FILES/config/ so it is synced to the user's config/ volume via rsync --ignore-existing on first container start
• In run-all.sh, detect changes to composer.local.json at runtime and re-run composer update only when needed; users who add extensions with composer dependencies should manually add entries to config/composer.local.json
• If composer.local.json is missing or has an empty include array, use the build-time autoloader as-is
• Set $smwgConfigFileDir in CanastaDefaultSettings.php to store .smw.json on the persistent volume (config/smw/)
• Auto-run rebuildData.php for newly-setup SMW wikis: snapshot .smw.json wiki IDs before run_autoupdate (which triggers setupStore.php via hooks), then run rebuildData.php for any new entries; supports wiki farms with per-wiki detection

Closes #84

Merge order: This PR is 1 of 4 — merge first, then CanastaWiki/Canasta#578, then CanastaWiki/Canasta-DockerCompose#91, then CanastaWiki/Canasta-CLI#236.

Test plan

• Build CanastaBase image, then Canasta image on top, and verify no per-extension vendor/ directories exist under canasta-extensions/ (e.g. canasta-extensions/CirrusSearch/vendor/ should not exist)
• Verify composer.local.json exists in the built image with specific extension entries (no wildcards)
• Verify .composer-deps-hash exists in the built image
• Verify SMW classes are in the unified autoloader: php -r "require '/var/www/mediawiki/w/vendor/autoload.php'; echo class_exists('SMW\Setup') ? 'OK' : 'FAIL';"
• Fresh canasta create: verify config/composer.local.json is synced from the image on first container start
• Enable SMW via wfLoadExtension('SemanticMediaWiki'); enableSemantics('localhost'); and verify setupStore.php runs automatically via update.php hooks and rebuildData.php runs afterward
• Verify config/smw/.smw.json is created on the persistent volume with a key for the wiki ID
• Wiki farm: add a new wiki and verify rebuildData.php runs only for the new wiki
• Test runtime: manually add a user-extension entry to config/composer.local.json, restart container, verify composer update runs
• Test runtime: restart without changes, verify composer update is skipped
• Test runtime: delete config/composer.local.json, restart, verify build-time autoloader is used as-is

[yaronkoren]

This looks amazing. I have one question: does CanastaBase specifically need to set $smwgConfigFileDir? Ideally, all the extension-specific stuff would go in Canasta.

[cicalese]

Good point, but CanastaDefaultSettings.php exists in this repo. If we put the change in Canasta, we'd have to do something fancy like sed the file, which is always dangerous, or create another file that CanastaDefaultSettings.php provisionally includes. Both approaches seem like overkill for this one setting, although I do agree it feels wrong to have CanastaBase include something outside its scope. That being said, Semantic MediaWiki has a lot of special handling.

[yaronkoren]

Okay, that makes sense. Perhaps ideally there should be a second, Canasta-specific default settings file, but it seems like overkill just for a single line. And obviously SMW is a special case.

[github-actions]

🐳 The image based on a54f561a commit has been built with 1.43.6-20260213-85 tag as ghcr.io/canastawiki/canasta-base:1.43.6-20260213-85

[yaronkoren]

Okay, this looks great. Just one other question (I think): does the addition of symlinks here mean that the create-symlinks.sh script can/should be simplified?

[cicalese]

No. It just needs the canasta-* symlinks early for the bundled extensions. The full create-symlinks.sh is necessary later.

[yaronkoren]

Does that include create-symlinks.sh's handling of "bundled" extensions? (I assume "bundled" here, in both your and create-symlinks' parlance, means the 150+ extensions of Canasta, not just the 20 or so extensions bundled with MediaWiki.)

[cicalese]

Yes, bundled extensions includes both.
It needs to generate the symlinks for the bundled extensions and skins when it builds the image so it can create the default composer.local.json file. But, later, at runtime, it needs to do so again and then add the user extensions and skins, potentially overriding some bundled extensions. It needs to repeat that process at every restart, and it needs to repeat the part for bundled extensions and skins in case somebody removed a user extension or skin that had been overriding a bundled extension or skin. (I asked Claude the same question, and it got it wrong. Score 1 for the human.)

[yaronkoren]

Oh yeah, that's true, I forgot about the case where someone overrides a bundled extension, then removes their override... just like Claude did. :(

[yaronkoren]

Thank you!