This is a collection of recipes for just, making interactions with common tools in PHP development a bit easier.
Clean up build artifacts
Install dependencies with decomposer
Examples:
# Install production dependencies
just decomposer
# Install production + development-only dependencies
just decomposer devRun phpcs to verify the defined coding standard. If no standard is selected it will
pick /var/www/libs/lunr-coding-standard/Lunr/ by default. You can override this with
either a LUNR_CODING_STANDARD environment variable, or a default_coding_standard just
variable.
You can specify a bootstrap file and/or define custom installed_paths if your coding
standard needs them.
The recipe will automatically pass --report-checkstyle=build/logs/checkstyle.xml to phpcs
if it detects that it's run from GitHub Actions.
Examples:
# Check against the "PSR12" standard
just phpcs PSR12
# Check against the "Lunr" standard, specify the bootstrap file to use and with installed_paths to set
just phpcs Lunr bootstrap.php third-party/slevomat/Run phpcbf to automatically fix code to conform to the defined coding standard. If no
standard is selected it will pick /var/www/libs/lunr-coding-standard/Lunr/ by default.
You can override this with either a LUNR_CODING_STANDARD environment variable, or a
default_coding_standard just variable.
You can specify a bootstrap file and/or define custom installed_paths if your coding
standard needs them.
Examples:
# Check against the "PSR12" standard
just phpcbf PSR12
# Check against the "Lunr" standard, specify the bootstrap file to use and with installed_paths to set
just phpcbf Lunr bootstrap.php third-party/slevomat/Print the list of Sniffs included in the defined coding standard. If no standard is
selected it will pick /var/www/libs/lunr-coding-standard/Lunr/ by default. You can
set a different default with either a LUNR_CODING_STANDARD environment variable, or a
default_coding_standard just variable.
You can specify a bootstrap file and/or define custom installed_paths if your coding
standard needs them.
Examples:
# List the Sniffs in the "PSR12" standard
just phpcs-sniffs PSR12
# List the Sniffs in the "Lunr" standard, specify the bootstrap file to use and with installed_paths to set
just phpcs-sniffs Lunr bootstrap.php third-party/slevomat/Run phpstan to statically analyze the code. You can pass the phpstan level you want to
check for as an argument. If no default level is found it will assume level 0.
Examples:
# Run phpstan and use whatever level is configured as the default
just phpstan
# Run phpstan with level 10
just phpstan 10
# Run phpstan with level 10 and set the output format as "prettyJson"
just phpstan 10 prettyJsonRun phpunit to execute the unit tests. You can optionally pass the name of a testsuite to only
run tests included in that testsuite.
The recipe will automatically pass --log-junit=build/logs/junit.xml --coverage-clover=build/logs/clover.xml
to phpunit if it detects that it's run from GitHub Actions.
Examples:
# Run all unit tests
just phpunit
# Run all unit tests in the 'Example' testsuite
just phpunit ExampleGenerate release notes based on the git commit log. You can pass a tag name, branch name or commit hash to generate release notes for all changes since then. By default it will take the latest tag.
The recipe expects the first line of the git commit message to follow a specific format:
(General|CI|Database|<component>): <message>
Release notes are then generated in this order:
- General (global changes, dependency updates, etc)
- CI (Changes related to CI workflows, phpunit/phpstan/phpcs fixes, etc)
- Database (Changes to the database schema/migrations)
- Remaining changes grouped alphabetically by the '<component>' specified in the commit message
Examples
# Generate release notes for all changes since the last tag
just release-notes
# Generate release notes for all changes since tag '1.0.0'
just release-notes 1.0.0Check conformance to REUSE with reuse-tool
Examples:
# Check conformance to REUSE
just reuse-lintAnalyze SQL code with sqlfluff.
You can specify the path where sqlfluff should look for files. By default this is tests/statics/sql.
You can set a different default path by setting a SQLFLUFF_PATHS environment variable or a
sqlfluff_paths just variable.
You can also specify the dialect sqlfluff should use to parse the SQL code. By default this is mariadb.
You can set a different default dialect by setting a SQLFLUFF_DIALECT environment variable or a
sqlfluff_dialect just variable.
The recipe will automatically pass --disable-progress-bar to sqlfluff if it detects that it's
run from GitHub Actions.
Examples:
# Check test statics against the 'mariadb' dialect
just sqlfluff tests/statics/sql
# Check migrations against the 'sqlite' dialect
just sqlfluff docs/database/updates sqliteAnalyze SQL code with sqlfluff and automatically fix issues.
You can specify the path where sqlfluff should look for files. By default this is tests/statics/sql.
You can set a different default path by setting a SQLFLUFF_PATHS environment variable or a
sqlfluff_paths just variable.
You can also specify the dialect sqlfluff should use to parse the SQL code. By default this is mariadb.
You can set a different default dialect by setting a SQLFLUFF_DIALECT environment variable or a
sqlfluff_dialect just variable.
The recipe will automatically pass --disable-progress-bar to sqlfluff if it detects that it's
run from GitHub Actions.
Examples:
# Check test statics against the 'mariadb' dialect and automatically fix issues
just sqlfluff-fix tests/statics/sql
# Check migrations against the 'sqlite' dialect and automatically fix issues
just sqlfluff-fix docs/database/updates sqliteCheck for spelling mistakes with typos
Examples:
# Check for spelling mistakes
just typos