We have decided to no longer ask users to create GitHub issues for
feedback as this doesn't work well with how we work.
- drop the issue template for technical feedback
- in the README, link to GitHub discussions instead of issues
Fixes#1500
As we'll need to have `build/logs/` for the merged coverage data
anyway, there is no point to have the separate coverage files
in `.Build/coverage/` instead of in `build/coverage/`.
Now the setup is more consistent.
Please note that this only affects the CI builds as we usually
only collect coverage data there for the pull requests.
As ts is usually understood as TypeScript instead of TypoScript.
TYPO3 itself also changed its file extension from `.ts` to `.typoscript`.
We reflect that by adopting the script name.
Resolves: #1385
This is necessary as older versions block installation of Symfony 7
components.
We also keep 0.6 as 0.8 drops support for older Symfony versions
Resolves: #1113
With #1289 the `nodejs` dependency management has
been changed from `yarn` to `npm` missing the one
or other important requirement.
This change streamlines the management by ...
* adding a `.nvmrc` file to the repository root to
allow automatic nodejs/npm switch if the nvm shell
switching is available on the host system.
* adding a `.npmrc` file to specify the lock file
version and engine option.
* adding `nodejs` and `npm` version constraints as
`engine` specification to the `package.json` file.
* remove `package-lock.json` from `.gitignore` and
add it to the repository to ensure reproducable
setups - which becomes more important if extension
get custom backend/frontend modules and javascript.
* adding `package-lock.json` to exclude it from archive,
due to remove from the `.gitignore` file.
* ensuring that new development files are excluded from
packaging and publishing.
* use `npm ci` in GitHub action workflows to install
from the lock-file.
Note: This change unblocks adding `npm` dispatching
to `Build/Scripts/runTests.sh`.
Resolves: #1301
Related: #1289
Allow others to easily provide feedback on technical decisions.
The issue template should make people more invited to share their own
feedback.
Resolves: #1235
Command for rendering:
./Build/Scripts/runTests.sh -s docsGenerate
or just:
composer docs:generate
The reference to the TYPO3 Documentation Rendering Guide was adjusted as the Quickstart page does not exist anymore.
Additionally, the genindex isn't supported anymore. It is planned to consider the `index` directive in the global search on docs.typo3.org.
Resolves: #1189
Tools that are downloadable should in general be downloaded during
the CI runs, not stored in the repository.
As the only PHIVE PHAR we're using is PCOV (for code coverage, which
we usually only run on CI), we can skip providing PHIVE and rely on
CI to provide PHIVE for us. This leaves only PCOV to be installed
via PHIVE.
Fixes#267
This is a TYPO3 extension, a library.
We do not track the `composer.lock` file for that reason.
Composer itself offers an option to prevent generation of the file.
This is now configured to prevent the creation of the file.
That should prevent issues with local version of the file.
One might change the `composer.json` version constraints but updates
might fail due to locked version constraints.
This no longer happens if no locked version, due to missing lock file,
exist.
Composer would render warnings when using `composer install` without a
lock file. That's why we update the CI commands to use `composer update`
instead. That warning was already rendered within CI due to missing
file.
The following are changed:
- web-dir: ".Build/public" => ".Build/Web"
- bin-dir: not specified, defaulted to .Build/vendor/bin
=> ".Build/bin"
The vendor-dir was alreaday ".Build/vendor" and is left
unchanged.
Since the above paths may be used in scripts, composer.json,
build pipelines, configuration etc. it facilitates
contribution across various extensions (and the core) if
the same defaults are used.
The goal of patches related to #802 is to unify the paths
across TYPO3 extensions, specifically focusing on the
"official" extensions (such as tea, Documentation examples
extension etc.).
- .Build has already been well established (and is used by
"tea" as well.
- web-dir (".Build/Web") is currently not used consistently
(across official extensions). Either ".Build/public", ".Build/Web"
or ".Build/web" or "public" is used. We use ".Build/Web"
now as that is already well established in "styleguide"
and other extensions. (This choice is not better than
the other, but is more commonly used and has led to a
consensus in preliminary decision making process.)
- bin-dir: Here ".Build/bin" is mostly used (if defined at all)
- vendor-dir: Here ".Build/vendor" is mostly used (if defined
at all)
Related: #802
