Note that this happens for other semantic extensions, too. I can confirm Semantic Compound Queries and Semantic Breadcrumb Links. I will have to look once I have time to which extensions are at play, too.

See also CanastaWiki/Canasta#251

Suspicion is that autoloading files via "composer.json" is causing the issue: https://github.com/SemanticMediaWiki/SemanticMetaTags/blob/3.0.0/composer.json#L44 I do not know for sure if this is the cause.

You are correct that autoloading is causing the issue, but let me fully explain the issue, since I discovered the same problem in another extension (which it turns out is reported in Canasta issue #251.

It's not the autoload stanza by itself in composer(.local).json (which allows you to specify additional paths and classes to add to the autoload.php), but rather the fact that Composer generates an autoload.php and related files during "installation" (in the vendor directory).

Removing dependencies in Composer

The correct process for removing a problem "library" such as SemanticMetaTags from Composer is to first delete the line from (composer.json or) composer.local.json and then issue a composer dump-autoload command which causes Composer to regenerate the vendor/autoload.php and related files.

Same error in SemanticBreadcrumbLinks

I'm getting this same reported error from the SemanticBreadcrumbLinks extension, and we can see that the classes are referenced in the generated autoload files:

grep -ril SemanticBreadcrumb ./vendor/
./vendor/composer/autoload_files.php
./vendor/composer/autoload_classmap.php
./vendor/composer/autoload_static.php
./vendor/composer/autoload_psr4.php

Let's try our temporary workaround

1. Remove SemanticBreadcrumbLinks from composer.local.json
2. Re-generate the autoload files.
3. Run composer update to see if it works now.

sed -i /SemanticBreadcrumbLinks/d composer.local.json && composer dump-autoload && composer update

truncated output showing that composer update worked:

Generating optimized autoload files
57 packages you are using are looking for funding.
Use the composer fund command to find out more!

The root cause

The root cause of this problem is that a lot of "older" MediaWiki extensions or "simple" extensions with one class file often do not follow PSR1 or PSR4 auto-loading techniques where the code for classes is separate and distinct from other 'plumbing' code. For example, it's bad practice to have the same file hold a class definition AND also have it die() if some constant like MEDIAWIKI is not defined. See the list of places where [https://codesearch.wmcloud.org/things/?q=not+a+valid+entry+point](not a valid entry point) is used. It's fine to do that in a settings file, but not if that same file is autoloaded.

Proper examples

See the autoload section of composer.json in SemanticMediaWiki v4.1.2 offers a full range of the Composer autoload keys and conventions.

And remember, Composer autoloading (for dependency management) is separate but related to the MediaWiki autoload functionality in core and configured in extension.json

There's a simple classmap example of the CDB library (not MediaWiki extension). CDB is installed by Composer and does a straight require of ../vendor/autoload.php in its sources.

Fixing SemanticMetaTags

I think the correct fix for SemanticMetaTags is to remove DefaultSettings.php from the autoload['files'] section of composer.json. The only code that needs it is SemanticMetaTags.php in the load() method which does its own require.

Your workaround does not work for me because I have multiple problematic extensions in my composer.local.json file.

Is your suggested permanent fix seeking something like this: CanastaWiki/Canasta#280 (comment)?

Did not try the fix, but the temporary workaround does not work for me.