Replies: 2 comments 1 reply
|
For Pest itself, the repository's current linting contract is Laravel Pint plus Rector, not PHPCS. The relevant Composer scripts are: You can see those scripts in composer.json, the project-specific Pint rules in pint.json, and the contributor workflow in CONTRIBUTING.md. For an application's own Pest tests, Pest does not require a particular style tool. PHPCS is still fine if that is the team's standard, but PSR-1's "side effects" rule is a poor fit for Pest test files because top-level test declarations are executable by design. Scope or exclude that sniff for the tests directory, while keeping the rest of the rules you need, rather than changing valid Pest syntax to satisfy it. So there is no need for a separate pretty-pest dependency when contributing to Pest core: use the repository's Composer scripts. In a downstream project, choose Pint or configure PHPCS around Pest's declarative test style. |
|
The repository appears to use Laravel Pint and Rector rather than PHPCS as its primary coding-standard tools. For PEST tests, it would be best to follow the project’s existing formatting configuration instead of adding a separate PHPCS standard that could conflict with PSR-1. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Which is the coding standard for PEST? I don't see a phpcs.xml file in the repo. I wonder if there is a preferred PHPCS when writting tests for PEST that doesnt collide too much. I've noticed that PSR-1 is problematic for rules like
PSR1.Files.SideEffects.FoundWithSymbols,I saw this project to provide some sort of standarization worksome/pretty-pest but looks abandoned...
All reactions