Uploaded image for project: 'Plugins'
  1. Plugins
  2. CONTRIB-6209

Ideas for improving distribution

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Deferred
    • Icon: Minor Minor
    • None
    • 3.0.3
    • Local: Code checker
    • None
    • MOODLE_30_STABLE

      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.

            moodle.com Moodle HQ
            bushido Mark Nielsen
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved:

                Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.