Skip to content

Contributing Workflow

Warning

Before helping out, please be sure to review the contributing prerequisites

Working on Tasks

Overall you should be able to follow our GitFlow process

  1. Find a task in the PS Unassigned Backlog's > Genesis Sprint
  2. Notify the Reporter that you're interested in getting started
  3. Assign it to yourself, refine, and estimate the task
  4. Pull it into your sprint when you don't have more pressing client work
  5. Mark it as in-progress.
  6. Determine where you should commit your changes:

    • If you're working on fixing or modifying existing Miva store templates or CSS/JS plugins that are used by the Genesis framework, you can find & update the corresponding package in mvps-genesis/generator-quickstart/app/templates/themes/genesis/src/extensions
    • Otherwise, if you're adding a new feature, package, and component that should ship at the theme level of Genesis (Meaning you want the source of your package to be easily editable by developers using Genesis) then develop it as it's own package under mvps-genesis/browse/optional-extensions by creating a new directory to encapsulate your package (ex. mvps-genesis/browse/optional-extensions/your-new-feature){target=_blank}.
      • Within your feature's package, there is a common directory structure that they should follow. Here is a full example showing most/all possible places where you might add new code. When making your package, only add the files/folders that apply to you.
        • optional-extensions/your-new-feature/
          • lib/
            • js/
              • yourNewJsFile.js
            • scss/
              • yourNewScssFile.js
          • miva-templates/
            • readytheme/
              • contentsection/
                • your-new-content-section.mvt
            • your-new-page.mvt
          • miva-server/
            • your-new-app/
              • your-new-script.php
          • index.js
          • index.scss
      • Please note: if you're adding package that will be pnpm installed, the create the index.js and/or index.scss with very minimal content that imports the bulk of the scripts in lib/js and/or lib/scss.
      • You will also need to write some documentation about how to install/use your package under the docs/ folder. For example:
        • docs/features/packages/
          • your-new-feature.md
    • If your new feature is more of a utility based package meaning that you want to control the source of the code and have it available through the monorepo and controled with PNPM, you would elect to create a new package in /packages. Packages in this folder are included in the monorepo. Good examples of packages that work well with this are the Event Bus and PageManager classes that are used by Genesis, but should not be modified by developers on a per project basis. These packages we want to control the updates of and keep a consistent code base across genesis projects.
      • Within your feature's package, there is a common directory structure that they should follow. Here is a full example showing most/all possible places where you might add new code. When making your package, only add the files/folders that apply to you.
        • packages/your-new-feature/
          • lib/
            • js/
              • yourNewJsFile.js
            • scss/
              • yourNewScssFile.scss
          • miva-templates/
            • readytheme/
              • contentsection/
                • your-new-content-section.mvt
            • your-new-page.mvt
          • miva-server/
            • your-new-app/
              • your-new-script.php
          • index.js
          • index.scss
  7. Create a branch on the from Jira using our branch-naming conventions.

    • For example:
      • feature/PS-1234-summary-of-feature
      • bugfix/PS-1234-summary-of-bug
  8. Apply the changes to your branch and your own personal dev store.
    • Please note: We do not want to continue to develop features on the staging store; please be sure to use your own store for development.
    • Follow the local development workflow and deploying a build to FTP instructions.
    • If applicable, make sure to update version numbers appropriately if you are working on an existing extension or package.
  9. Commit your changes & create a pull request when you're done.
    • Copy and fill-out the pull-request template by clicking on the link below the text-area of the pull-request creation form.
    • Be sure that at-least two of the lead contributors are added as Default Reviewers (you will need two of their approvals to complete the merge).
  10. Your pull request will be reviewed by the lead contributors.
  11. Once your pull request has been merged into develop, you will need to migrate your changes from the repo/your-dev store into the the staging store store.

Installing Dependencies for All Packages

  • To recursively install dependencies for packages within the monorepo run the following command:

    • pnpm -r i which stands for pnpm recursive install
    • Alternatively, in the root of the repo, you can run pnpm run bootstrap
  • Make sure you run this script every time you merge branches or create a new branch from develop.

Attention

Do not run pnpm install in any of the managed sub-packages! This will cause issues with testing due to improper node_modules folder format.

Adding a New Dependancy

See pnpm add documentation for more information about the add command. Here are common use cases for our project:

  • Add a dependency to a SPECIFIC package in the monorepo. Use the filter flag to specify an exact package.
    • pnpm -r add <package>[@version] --filter <package-name>
    • Add the -D or --save-dev flags to add it to devDependencies

Note

You can also cd into a specific package folder and run the standard pnpm add <package>[@version] command.

  • Add a dependency to ALL packages in the monorepo.
    • pnpm -r add <package>[@version]
    • Add the -D or --save-dev flags to add it to devDependencies

Note

Learn more about pnpm filtering here.