Repository navigation
Lint with the shared Pint config, and stop moving action pins backwards - #7
Merged
Merged
Conversation
**Style.** `vendor/bin/laranail-pint` resolves the one config in vendor/laranail/package-tools and errors when it is absent. Bare `vendor/bin/pint` takes a `--config` path that does not exist, silently falls back to its own defaults and exits 0 -- so twelve workflows in this family were reporting "code style clean" against a rule set no other package uses. Those now call laranail-pint, and this is what the shared config actually wanted: import order, `.` spacing, `=>` alignment, brace position, single-line empty bodies, phpdoc alignment. No behaviour changes; the suites are unchanged and green. **Pins.** The release.yml consistency pass had copied one repo's pins over fourteen others, and that repo was behind: `softprops/action-gh-release` went v3.0.3 -> v3.0.2 (v3.0.3 -> v2 in enumerator) and `anchore/sbom-action` went v0.24.2 -> v0.24.0. Pinning to a SHA is a supply-chain control, so a pin moving backwards is the one direction that must never happen by accident -- and nothing catches it, because the pin check verifies the SHA against its comment, not that the version moved forward. Both are on one pin family-wide now, at the newest release, with the exact release tag in the comment rather than a moving major. **And the alias debris.** Where the `$commandAliases` declarations were deleted, this also fixes the two command bases that read `$this->commandAliases` without declaring it (an `Undefined property` at construction, which took out `artisan package:discover`), a command that called a sibling by its deleted alias, a success message naming a command that no longer exists, and the docs that still documented the aliases as the way in.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lint with the shared Pint config, and stop moving action pins backwards
Style.
vendor/bin/laranail-pintresolves the one config invendor/laranail/package-tools and errors when it is absent. Bare
vendor/bin/pinttakes a--configpath that does not exist, silently fallsback to its own defaults and exits 0 -- so twelve workflows in this family were
reporting "code style clean" against a rule set no other package uses. Those now
call laranail-pint, and this is what the shared config actually wanted: import
order,
.spacing,=>alignment, brace position, single-line empty bodies,phpdoc alignment. No behaviour changes; the suites are unchanged and green.
Pins. The release.yml consistency pass had copied one repo's pins over
fourteen others, and that repo was behind:
softprops/action-gh-releasewentv3.0.3 -> v3.0.2 (v3.0.3 -> v2 in enumerator) and
anchore/sbom-actionwentv0.24.2 -> v0.24.0. Pinning to a SHA is a supply-chain control, so a pin moving
backwards is the one direction that must never happen by accident -- and nothing
catches it, because the pin check verifies the SHA against its comment, not that
the version moved forward. Both are on one pin family-wide now, at the newest
release, with the exact release tag in the comment rather than a moving major.
And the alias debris. Where the
$commandAliasesdeclarations were deleted,this also fixes the two command bases that read
$this->commandAliaseswithoutdeclaring it (an
Undefined propertyat construction, which took outartisan package:discover), a command that called a sibling by its deletedalias, a success message naming a command that no longer exists, and the docs
that still documented the aliases as the way in.