- 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
Having a consistent structure and order between the CI jobs and the
code coverage generation job makes understanding the GitHub Actions
configuration easier.
It also allows having a shared Composer cache between the non-coverage
jobs and the coverage job.
There is no need to have the code coverage data directly generated by
the tests run in a non-hidden directory. So now the code coverage is
recorded within `.Build/coverage`.
Only the merged coverage data still needs to be located in `build/logs`
as Coveralls (which we're planning to use) relies on this.
The installed Composer packages will be different depending on the
major TYPO3 version being tested and on the strategy for the
dependencies (highest, lowest). So it makes sense to have
separate Composer caches for these versions in order to avoid
cache misses.
The CI workflow with predefined GitHub actions had an empty `on:`
element, which is invalid. Use the correct event for manually
triggered workflow runs instead.
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.
It has turned out that having builds only for pushes (but not
pull requests) is not enough for triggering builds for PRs
from forks.
So we will need to live with pushes to non-PR branches other
than main not triggering a build, and having to create a
dummy draft PR for testing the CI build.
This reverts commit d1f02afe79.
Fixes#359
This will allow us to test things on the CI pipeline without
having to create a dummy/draft PR for this.
Hopefully, this will also allow builds for forks.
Composer versions 2.2.0 and 2.2.1 have a bug that breaks PHPUnit.
Until version 2.2.2 is released with a fix, we need to keep to
Composer 2.1 to keep the tests from breaking.
See https://github.com/composer/composer/issues/10387 for details.
If the CI build will do a composer update in the next step anyway,
there is no need to actually install any packages when requiring
the desired TYPO3 version.
Fixes#324
This now matches what the TYPO3 Core uses.
We still use the XLIFF 1.2 schema for validation as version 1.2
is the first fully ratified version.
Closes#198
