Skip to content

Conversation

@Tjitse-E
Copy link
Contributor

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • Other... Please describe:

What is the current behavior?

Currently, when mage-os/github-actions/coding-standard is used the Magento 2 coding standard is always used.

What is the new behavior?

If we want to make this the default PHPCS coding standard workflow we should add an option to specify a custom coding standard. This is usefull for vendors who want to modify/add sniffs to the official Magento 2 coding standards.

For example, we have excluded some rules

You can see the new options in action here

In addition to this, i've also added dealerdirect/phpcodesniffer-composer-installer, so all of the available phpcs standards in the project are automatically registered. The "Register Coding Standard" step became redundant and was removed.

Does this PR introduce a breaking change?

  • Yes
  • No

@Tjitse-E Tjitse-E requested a review from a team as a code owner September 22, 2023 09:47
working-directory: standard
run: composer require dealerdirect/phpcodesniffer-composer-installer

- name: Install Magento2 Coding Standard
Copy link
Member

@damienwebdev damienwebdev Sep 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these two things (the custom standard install and the Magento standard install) mutually exclusive? Wouldn't custom_standard have a dep on Magento?

run: composer require "magento/magento-coding-standard:${{ inputs.version || '*' }}"

- name: Register Coding Standard
- name: Install Custom Coding Standard
Copy link
Member

@damienwebdev damienwebdev Sep 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I foresee two situations for this action to be used:

  1. Extensions
  2. Stores

both of them will often have this extra repo already included in require-dev. Should we be the ones to install this? It seems like an unnecessary network IO if it is already installed. Perhaps #133 applies to this as well?

I don't personally think custom_coding_standard_repo is a good idea, though I like the ability to change the standard via coding_standard

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants