Problem/Motivation

I maintain a bunch of modules including Structure Sync, and have spent quite a bit of time recently trying to figure out how to optimize my (very limited) contribution time. To this end, I've found a bunch of tools and developed a bunch of best-practices to make it easier for me to jump into maintaining a module. (Admittedly, some of this productivity comes from consistency with other modules I maintain, so there is some level of self-interest in this issue.)

Also, I've found that defining a "recommended" way to set up a development environment makes it easier to write documentation, and also make writing "Steps to reproduce" in issues easier (i.e.: because they can start from a defined starting point.

Therefore, I would like to propose the following changes to the code in the 2.x branch:

  1. Update the GitLab CI config for consistency and to take advantage of the community's latest changes
  2. Update ddev/ddev-drupal-contrib for consistency and to take advantage of the community's latest changes
  3. Fix some phpunit issues identified in my development environment
  4. Set up PHPStan (PHPStan is a tool that does static analysis on a codebase to find bugs. PHPStan is run in our CI pipeline. PHPStan groups its lints into rule levels - currently PHPStan doesn't report any issues because we don't have a configuration file for it yet)

Proposed resolution

  1. Update .gitlab-ci.yml. Note the latest version at time-of-writing is 1.15.0.
  2. Run the ddev/ddev-drupal-contrib setup in this repo and commit the scaffolding to make setup easier. Note the latest version at time-of-writing is ddev/ddev-drupal-contrib 1.1.5.
  3. Run ddev phpcbf in the ddev-drupal-contrib environment to have it fix issues
  4. Create phpstan.neon and phpstan-baseline.neon files and update them to the highest level we can without errors. Initial tests suggest we can get it to level 1 right now.

Remaining tasks

  1. Merge request - merge request !56 created by @mparker17 in #2
  2. Community review
  3. Commit
  4. Release

User interface changes

None.

API changes

None.

Data model changes

None.

Issue fork structure_sync-3587224

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

mparker17 created an issue. See original summary.

mparker17 opened merge request !56

mparker17’s picture

mparker17
he/him
Primary language English
Location UTC-5
commented
Status: Active » Needs work

Seeing a test failure. I'll take a look at this.

mparker17’s picture

mparker17
he/him
Primary language English
Location UTC-5
commented
Issue summary: View changes
Status: Needs work » Needs review

Looks like there might have been some broken tests in the 2.x dev branch. I've fixed them here.

Now that all tests are passing, this is ready for review.

mparker17’s picture

mparker17
he/him
Primary language English
Location UTC-5
commented

Since ddev doesn't install add-ons automatically, I just pushed a commit to delete .ddev/addon-metadata/ddev-drupal-contrib/manifest.yaml so it doesn't show up as "changed" every time someone sets up the development environment.

I should post the steps to test (which I will turn into a documentation page similar to a docs page I wrote for Elasticsearch Connector)...

First-time setup:

  1. Clone the module
    Before this issue is merged, you have to run:
    git clone --branch '3587224-make-maintenance-easier' git@git.drupal.org:issue/structure_sync-3587224.git structure_sync && cd structure_sync

    But once this issue is merged, this step becomes simpler: 

    git clone --branch '2.x' git@git.drupal.org:project/structure_sync.git && cd structure_sync
  2. Ask ddev to set itself up using the config.yml file committed in this MR: ddev config --auto
  3. Download the add-ons we need: ddev add-on get ddev/ddev-drupal-contrib && ddev add-on get ddev/ddev-selenium-standalone-chrome
  4. Start ddev: ddev start

Before working on an issue:

  1. git switch to whatever branch/issue fork that I want to work on
  2. Install php dependencies: ddev poser (this step is copied from the ddev-drupal-contrib Install instructions)
  3. Make sure all files in the project are symlinked into the webroot properly ddev symlink-project (this step is copied from the ddev-drupal-contrib Install instructions)
  4. Install Drupal: ddev drush -y si standard
  5. Install Structure Sync: ddev drush -y en structure_sync
    Out of scope for this ticket, but in the future, we should consider writing a test sub-module that sets up structure sync and some taxonomies, blocks, and menu links to test with.
  6. Get a login link: ddev drush -y uli

After making changes in an issue...

  1. Run PHP lints: ddev phpcs, ddev phpstan
  2. Run tests: ddev phpunit
  3. Before I can run eslint, I have to install npm packages: ddev exec "cd web/core && yarn install"
    We could make this part of the "Before working on an issue" setup
  4. Then I can run eslint: ddev eslint