The `typo3/minimal` package is not maintained very much, and currently
cannot be used as a requirement to install the latest TYPO3 development
version (as it still depends on `dev-master`, not on `dev-main`).
In addition, not depending on it will allow us to find any missing
dependencies in our requirements that so far have been masked by
the `typo3/minimal` dependencies.
(This is the same as #520, but for GitLab CI.)
The acceptance tests have not been testing the extension itself,
have not been maintained for quite some time, and do not serve
as a good example anymore.
Until we have a proper set of example acceptance tests, we should
remove them.
Also drop the now-unused dependency on Codeception.
For non-Composer installations, all extension dependencies that are in
the `composer.json` should also be in the `ext_emconf.php`.
Even for extensions that are always installed (like frontend or fluid),
it is good practice to always make these dependencies explicit.
PHPUnit has dropped its dependency on Prophecy. In order to keep using
Prophecy in our tests, we need to add it as an explicit (development)
dependency.
Also, relying on transitive dependencies is bad practice anyway.
- Move npm tools and config to default places
- Remove now unnecessary config file parameter from npm scripts
- editorconfig and eslint config contradict, adapt editorconfig
- switch JS indent linting to TYPO3 coding standard of 2 spaces
- adapt composer scripts for new npm location
Now that we have added support for TYPO3 11LTS, we have been supporting
3 different TYPO3 LTS versions in the same branch. This has turned out
to be too much of a hassle when running the test. So now is the time
to drop support for 9LTS.
This fixes a missing Symfony polyfill for `str_starts_with` in
TYPO3 11.5.0 and 11.5.1, which fixes a crash in the unit tests with
TYPO3 11LTS and PHP 7.4 using the lowest possible Composer dependencies.
Add the full relative path to Composer-installed binaries to make
sure that are used instead of other versions that happen to be in
the path.
Also drop unneeded trailing slashes from directories used in
Composer scripts.
To avoid stating any untested compatibility with a (non-existent) PHP
version 7.5, the requirements in the `composer.json` need to provide
the patch-level version as well as `~7.0` works the same as `^7.0`,
while `~7.0.0` does not.
Downgrades of Composer packages do not work reliably
if a higher version of a package already is installed in `vendor/`.
This causes builds to use higher versions of packages than intended
if Travis CI has the corresponding version in the cached and restored
`vendor/` folder.
For GitHub actions, an explicit step is required to use a
specific PHP version. If this is not done, a default version
will be used (which makes the builds unpredictable).
