[CONTRIB-6209] Ideas for improving distribution

[sarjona]

btw... was thinking if maybe we could try to keep the moodlerooms/moodle-coding-standard auto-maintained, so any change in the standard is automatically populated there. I see you've the sync + manual review approach there.

Source: https://github.com/moodlerooms/moodle-plugin-ci/issues/18

It would be nice if it were auto-maintained, though I think an even better approach would be to replace it with Moodle's own official coding standard, distributed via Composer. The reason why I created the moodlerooms/moodle-coding-standard project was simply to make it easier to manage my dependencies for the moodle-plugin-ci project and also to know, for certain, that if the project is installed, then I don't have to install additional items in order to run some of the commands, EG: ensure local/codechecker is installed into the Moodle it is running against.

Two things I have encountered with the moodlerooms/moodle-coding-standard project:

• Must always depend on an official release of PHP_CodeSniffer. Recently I upgraded to a specific version in their master branch, and that worked well until I tried to pull the coding standard into another project. Composer doesn't like that I used dev-master and considered that release of the standard to be unstable.
• I had to remove the tests because they depend on Moodle's PHPUnit framework. I would hope this is a minor barrier.

So, if Moodle had its own official coding standard, distributed by Composer, then it can be easily reused by other projects, including Moodle itself. We could put it in Moodle's composer.json making it trivial for developers to run it against their code (or useful for CI). Another bonus, you can do something like this in the composer.json:

  "scripts": {
    "post-install-cmd": [
      "vendor/bin/phpcs --config-set installed_paths ../../moodlehq/moodle-coding-standard",
      "vendor/bin/phpcs --config-set default_standard moodle",
      "vendor/bin/phpcs --config-set show_progress 1",
      "vendor/bin/phpcs --config-set colors 1",
      "vendor/bin/phpcs --config-set severity 1",
      "vendor/bin/phpcs --config-set report_width auto",
      "vendor/bin/phpcs --config-set encoding utf-8"
    ],
    "post-update-cmd": [
      "vendor/bin/phpcs --config-set installed_paths ../../moodlehq/moodle-coding-standard",
      "vendor/bin/phpcs --config-set default_standard moodle",
      "vendor/bin/phpcs --config-set show_progress 1",
      "vendor/bin/phpcs --config-set colors 1",
      "vendor/bin/phpcs --config-set severity 1",
      "vendor/bin/phpcs --config-set report_width auto",
      "vendor/bin/phpcs --config-set encoding utf-8"
    ]
  }

Now you can use vendor/bin/phpcs AND vendor/bin/phpcbf and both default to the correct coding standard and our other various defaults. The only thing that is missing is some of the magic that local/codechecker does to ignore 3rd party libraries which you might be able to make another light weight package to house that logic and add it to the composer.json as well.

Anyways, just some ideas I have been thinking about. I know this will be disruptive for developers because it changes their workflow, but like most change, hopefully it is for the better.

---

Reporter: Mark Nielsen Original issue: https://tracker.moodle.org/browse/CONTRIB-6209

[stronk7]

Note that we already have split the standard to https://github.com/moodlehq/moodle-cs , that is published @ Packagist.

And now, the tools (local_ci, moodle-plugin-ci...) are picking it from there.

Only remaining bit is to automate local_codechecker to detect moodle-cs changes and incorporate them, surely something to be put on GHA hands, providing automatic PRs achieving that. In the mean time, manual copies from moodle-cs will be done.

[stronk7]

For the records, since https://github.com/moodlehq/moodle-local_codechecker/commit/8be89339db4982e9f884f12087dd9e6837a05e6a we are using dependabot to update composer dependencies (composer.lock).

And, soon, we'll run some job making the "vendoring" aka, given current composer.lock file, provide updates to the vendor that now we have in git.

Once that's done, this will be closed as completed.