Support strict (no ambiguous classes) mode for generating optimised autoloader

[acoulton]

I'd love a composer install --optimize-autoloader --prevent-ambiguous (or similar named) option to make the install fail (rather than just print a warning) if it finds ambiguous class definitions.

The resolution of ambiguous class names is platform-dependent (the order composer finds the files varies between filesystems) which can lead to composer autoloading a totally different implementation of a class between development / build / production instances. Similarly classes contained in files that don't match the PSR-0/4 definition won't cause issues locally but may be found and used when the classmap is generated. For example this can happen if working / backup files are accidentally committed, or if a (badly-configured) dependency with a loose psr-0 definition comes with test / example files.

It can be very hard to debug and trace the problems this causes. They can arise at any time (even if the composer dependencies don't actually change), so a developer might not always notice them. Often the "Ambiguous class resolution" warnings will only arise within a remote build / deployment process and not be noticed - particularly if the composer command output doesn't appear in deployment logs.

So I'd like to be able to opt-in to have composer fail with an error if ambiguous classes are found, to force the end-user to fix that rather than hope the resolution is always going to be correct now and in future.

I'm happy to work on a PR if you agree this is a good idea?

[alcohol]

I am not opposed to this, I am just not sure if it should be --prevent-ambiguous or if maybe a more generic --strict would be more suited.

[acoulton]

Yeah I wondered about --strict too, my only reservation was whether then that would create an obligation over time to make sure it was strict about everything to avoid confusion about what it was / wasn't enforcing.
Possibly the simplest way to do a generic --strict would be to bind to the IOInterface somehow and fail if any warnings or errors were displayed - although from a quick scan of the code it looks like io->writeError is used for quite a bit of non-error informational and debug logging too so that might be more complex than it seems.

[alcohol]

That's because stderr is not only for errors, unlike a lot of people seem to think. Writing to stderr does not imply something went wrong and it is a horrible way to make bad assumptions.

[acoulton]

That's true, though arguably fair enough given the misleading "error stream" naming. But as an outsider when I looked at a php method called ->writeError I wasn't thinking about shell-level stderr. I'd thought / hoped it was more of a higher-level severity method. Anyway, I'm not here to argue about naming.

Very happy to look at suggestions for how I could implement a robust and future-proof generic --strict flag. Possibly still at the IO level but based on the <warning> etc formatting tags in the messages themselves rather than which stream they're on?

[alcohol]

Unfortunately I do not think it will be quite that simple. Cannot think of a proper solution of the top of my head either though.

[acoulton]

Just to confirm that definitely won't work - I just noticed abandoned packages are displayed as warnings with equal severity/formatting to ambiguous classes. It looks to me like adding a generic --strict option would be an order of magnitude larger than what I'd envisaged just to enforce no ambiguous classes.

What other warnings does composer issue during install that might actually have an impact on (and particularly, platform-specific impact) production behaviour? I'm not really aware of anything else that it would be important for --strict to catch at the moment - so maybe a specific flag is more appropriate after all?

[Seldaek]

I also don't think it's worth having a --strict, given that the scope might change over time, it's best to have specific flags.

Perhaps --classmap-strict would be good/short enough?

[acoulton]

--classmap-strict seems good to me.

[ashnazg]

Just stumbled into this need... is this feature on hold?

[alcohol]

Development of nice-to-have features is very much up to opensource contributions. Feel free to submit a PR.

[Seldaek]

It's somewhat related to #7421

[ashnazg]

I toyed with adding this config option yesterday, but couldn't see a direct way to access the setting at the two points where the Ambiguous warning is recognized, much less how to set the execution as "failed" from the same points.

[fredden]

--strict-psr was introduced in #10886, which landed in Composer version 2.4.0. Does that satisfy this feature request?

[Seldaek]

I don't think so, this is about ambiguous classes (class names present more than once), not PSR validity.