README

RingierSA PHP Code Style

Installation

composer require ringierimu/ringier-code-style --dev

Usage

Fix code style

vendor/bin/ringier-code-style fix ...files...

Create the mago config file for IDE compatibility

vendor/bin/ringier-code-style config:dump --all

Upgrading from 0.x

1.0 formats with mago instead of PHP CS Fixer.

config:dump --php-cs-fixer, --styleci, --pint and --phpcs are removed, and the command errors if they are passed. Replace them in your composer scripts with config:dump --mago, or drop the call: fix falls back to the bundled mago.toml.
StyleCI is no longer supported. Disable it for the repository and delete .styleci.yml; otherwise it reverts mago's formatting. Delete .php-cs-fixer.php too.
fix and fix:stdin no longer accept PHP CS Fixer's options (--config, --dry-run, …), so an IDE's PHP CS Fixer integration pointed at this binary stops working.
fix now exits non-zero when a file fails to parse.
Re-dump the CI workflow with config:dump --workflow --force. 1.x calls fix-code-style.yml@1.x; the old @main caller keeps installing 0.x.

Fix code style automatically on every pull request

fix-code-style.yml is a reusable workflow. It fixes the PHP files a pull request touches and commits the result straight back to the PR branch. Drop the caller into your repository with:

vendor/bin/ringier-code-style config:dump --workflow

which writes:

# .github/workflows/ringier-code-style.yml
name: ringier-code-style

on:
  pull_request:

concurrency:
  # Cancel superseded runs on rapid pushes so two runs never race to commit fixes.
  group: ${{ github.workflow }}-${{ github.head_ref }}
  cancel-in-progress: true

jobs:
  ringier-code-style:
    # The job lives in the fixer's own repo, so a fix to it reaches every consuming repo.
    # Pin to a release tag: https://github.com/RingierIMU/ringier-code-style/releases
    uses: RingierIMU/ringier-code-style/.github/workflows/fix-code-style.yml@1.x
    with:
      runs-on: ubicloud-standard-2-arm
    secrets:
      # Organisation secrets: the Client ID and private key of a GitHub App installed on
      # this repository with the Contents: read and write permission.
      app-client-id: ${{ secrets.PR_SIGNING_BOT_CLIENT_ID }}
      app-private-key: ${{ secrets.PR_SIGNING_BOT_PRIVATE_KEY }}

Both with: inputs are optional: php-version defaults to 8.3 and runs-on to ubuntu-latest.

The two secrets are the Client ID and private key of a GitHub App installed on your repository with the Contents: read and write permission. In the RingierIMU organisation they already exist as the organisation secrets PR_SIGNING_BOT_CLIENT_ID and PR_SIGNING_BOT_PRIVATE_KEY; grant your repository access to them rather than creating a second app.

A GitHub App is used rather than the default GITHUB_TOKEN for two reasons:

Commits made with GITHUB_TOKEN do not trigger further workflow runs, so the pull request's required checks would never report against the style commit and the PR would stay blocked.
The commit is created through GitHub's GraphQL API, which signs it with GitHub's own key. It therefore shows as Verified and is accepted on branches that require signed commits.

Pull requests opened from forks are skipped, because forks receive no secrets.

Contriubutions

Update dependencies

make update-dependencies

Release

Run the Release workflow from the Actions tab (.github/workflows/release.yml). It builds the PHAR, commits it, tags it and publishes the release with the binary attached.

Leave version blank to bump the patch of the latest 1.x tag, or type an explicit 1.MINOR.PATCH to release something else. The first 1.x release needs 1.0.0 typed in.
Tick dry-run to build and verify without committing, tagging or publishing. The PHAR is uploaded as a run artifact so it can be inspected.

The workflow only runs from the 1.x branch (0.x is released from main), refuses a version that is not 1.x or is already tagged, and fails if the PHAR it built does not report the right version, does not carry the current stubs/ content or cannot format a snippet — the release commit is only made once those checks pass.

It needs the organisation secrets PR_SIGNING_BOT_CLIENT_ID and PR_SIGNING_BOT_PRIVATE_KEY (the same GitHub App used by the code style workflow) so the release commit lands Verified.

Build a binary locally

Not needed to release — the workflow above does it. To build one for testing:

make build VERSION=0.6.31

ringierimu / ringier-code-style

Package info

Security

Statistics