Scenario:¶

Someone transfers over contents of a production instance for local development. They copy "_assets" over to their local install (just because they "copy everything").

The file copying is done without respecting symlinks, so symlinks get turned into actual directories with actual, non-symlinked files. Depending on the deployment process, these symlinks may even have already been resolved on the upload to a production server (rsync dereferencing).

Resulting symptons¶

When now the development instance issues a composer update followed by composer dump-autoload, any updated assets will NOT be updated in the existing directory.

This could lead to odd issues where typo3 cms-... packages do not deliver the right CSS+JS files. See slack https://typo3.slack.com/archives/C025BQLFA/p1716455213954609

Workaround¶

One can remove the whole `_assets` directory and then let `composer dump-autoload` do its magic. However, people may not even notice this, as no errors are shown.

Reasons and suggested change¶

The PackageArtifactBuilder just assumes, everything is good, when the expected directory can be resolved. If it's actually a symlink is not evaluated.

My proposal would be to ensure that the target resource path is actually a symlink, and leads to the assumed symlink target. `composer dump-autoload` should then report a warning, if a directory does not match that expectation. It does not create any hard failures, so if anyone is using non-symlinks in production, nothing will be deleted/recreated, and continue as-is.

Additionally it would be nice if the Admin Tools > Environment > Directory Status could also reveal this warning.

Related documentation change: https://github.com/TYPO3-Documentation/TYPO3CMS-Reference-CoreApi/pull/4440