typo3/cms-composer-installers:^4 compatibility will need some work

[jonaseberle]

The new generation of typo3/cms-composer-installers uses URLs to EXT:.../Resources/Public/... that must be generated via the FileResource API.

This will need changes to our test extensions and documentation. We will probably have to develop a solution how our JavaScript can dynamically include JavaScript from e.g. the site package.

Or just tell users they shall dump their loadable assets to some folder in ./public now. But this won't be a nice solution if people want to dynamically load assets from a 3rd party extension.

Relates: https://github.com/TYPO3/CmsComposerInstallers/issues/131

[jonaseberle]

See https://forge.typo3.org/issues/99203 for TypoScript solutions and comments on https://typo3.slack.com/archives/C02JDFFLBEW/p1669449850484169

[jonaseberle]

We could...

1. make inject a string / stdWrap (probably with recommendation to use {path : EXT:...})

   • Requires users to update their cookieman configuration for injected local URLs.
   • Does not solve the greater problem of referencing arbitrary assets from JS or from an external system.
   • Could benefit from cache-busting param feature (probably only v12+)

2. have a middleware that keeps /typo3conf/ext/.../Resources/Public/... working by either readfile()ing or forwarding (307) to the final location. For performance it could transparently add symlinks on the fly if the file system is writable (to be used for consecutive requests).

   • Benefits all use cases that want to continue using known local URLs.
   • For sending via PHP: Setting headers adds an unnecessary layer and potential source of problems. Doing a local request for passing through web server's headers could be a performance problem or fail in some environments.
   • For forwarding: Needs validation if it works reliably with all types of assets in all browsers (should in theory).

3. have a composer plugin that manages symlinks for installed/uninstalled typo3-cms-extension packages.

   • Benefits all use cases that want to continue using known local URLs.
   • composer-only is not a problem: the new folder structure only applies to composer-installs
   • it might be non-trivial to replicate https://github.com/TYPO3/typo3/blob/12.1/typo3/sysext/core/Classes/Composer/PackageArtifactBuilder.php#L269 outside of a TYPO3 context (the exact way of building the _asset path is not public API AFAIK)

[jonaseberle]

Relates: https://github.com/a-r-m-i-n/min/issues/12

[jonaseberle]

By using 1. now we are trying to stay close to "how it is supposed to work".