User story

As a developer I want to refer to this repo using versioned tags instead of "trunk" branch.

How to reproduce the problem

For referring to this repo we should add the branch trunk.

Describe the solution you'd like

Use a release version like WooCommerce or other repos in do.

Acceptance criteria

• We should be able to load the repo using for example: https://gitpkg.now.sh/woocommerce/grow/packages/js/storybook?1.0.1

Describe the bug:

When WooCommerce is not installed, the admin notices from the compat checker compatibility checks are not triggered.

Steps to reproduce:

1. Setup the compat checker code in any of the plugins by following the Getting Started instructions here: https://github.com/woocommerce/grow/tree/trunk/packages/php/compat-checker#getting-started
2. On a fresh WordPress installation without WooCommerce installed, activate the plugin.
3. No admin notice is shown.

Expected behavior:

An admin notice saying that WooCommerce should be installed and activated should be displayed.

Actual behavior:

No admin notice is shown.

Additional details:

The issue is that the manage_woocommerce capability did not exist before WooCommerce was installed and per this code no admin notice is displayed: https://github.com/woocommerce/grow/blob/trunk/packages/php/compat-checker/src/Checks/CompatCheck.php#L68

User story

As a developer I want to see color highlights in the console output when I run a command.

How to reproduce the problem

Run a command using a shell. Like storybook the command works but is not showing colors.

Describe the solution you'd like

The command works and shows colors.

Describe alternatives you've considered

@tomalec mentioned this library

Acceptance criteria

• The command works as before.
• The command shows color highlighting
• The code is safe and maintanable

Unknowns

• Safety of this library
• Research for alternatives

UserDeveloper story

As the github-actions/actions/phpcs-diff/action.yml developer, I want to maintain the least amount of code possible.

Is your feature request related to a problem?

We used to have a problem that was worked around by #27
that originates in exussum12/coverageChecker#72, and was already fixed at source.

How to reproduce the problem

Run phpcs-diff action when no changes are made.

Describe the solution you'd like

Remove no longer needed code, once the https://github.com/exussum12/coverageChecker >1.0.2 is released

Describe alternatives you've considered

Technical

Figma link

n/a

Acceptance criteria

Unknowns

Out of bounds/rabbit holes

Event tracking

n/a

Describe the bug:

The Compat Checker framework adds dismissable notices using the WC_Admin_Notices class. These notices appear even after the plugin is deactivated.

Steps to reproduce:

1. In the plugin header of the plugin that uses compat checker, set the WC tested upto header value to a version lower than the currently active WooCommerce.
2. This should trigger a notice saying This plugin is not tested with this version of WooCommerce
3. De-activate the plugin that uses compat checker.
4. Notice the warning notice triggered in step 2 still appears.

Expected behavior:

All notices added by the plugin should be removed on de-activation.

Actual behavior:

Notices appear even after the deactivation of the plugin.

Developer Story

As a WooCommerce extension developer, I'd like to permanently make the warning notices dismissible while using the compat checker. The current behaviour is that the warning notices are only dismissible for the current page. This can be resolved using the WooCommerce Admin notices whenever available. WooCommerce notices may not be available when WooCommerce is not activated.

Describe the bug:

When running npm run doc:tracking in the last version of GLA I got the next error

/node_modules/jsdoc-advanced-types-plugin/index.js:105
				throw "infinite loop!!!"
				^
infinite loop!!!
(Use `node --trace-uncaught ...` to show where the exception was thrown)

After investigating the code, there is a check for the iterations, in case iterations are > 100 an exception is thrown stopping the process and not updating the docs.

ℹ️ I found that just using break; instead of the throw statement, we can generate the docs and still prevent potential infinite loops.

Steps to reproduce:

1. Get the latest develop branch in GLA.
2. Run npm run doc:tracking

Expected behavior:

A README.md for tracking is generated correctly without errors.

Actual behavior:

A README.md for tracking is not being generated.

User story

As a developer I want to safely commit and ship new code to this repo in an automated way.

How to reproduce the problem

The repository doesn't have yet any CI/CD setup, neither linters or tests, this makes the code and the repositories using our packages unsafe and tedious to maintain.

Describe the solution you'd like

Implement CI/CD with linters and tests.

Acceptance criteria

• There is a test suit for the different packages in the repo
• There is a linter for PHP
• There is a linter for CSS
• There is a linter for JS
• There is an automated task that runs all of those on each PR (aka, Github Actions)

This is kind of a follow up from #6 (comment)

User story

It's rather a cosmetic 💅 problem, but I think it'd be nice to settle on good names, as later it could be hard to ever them.

As a user of Grow tools, I'd like to write less code/configs/ etc. and avoid repetition.
Also when it comes to the package name.

Is your feature request related to a problem?

Currently, we use a format of woocommerce-grow-{package-name} for our tools here. (As it was introduced in the very first package)

It has a set of benefits:

• states the full product name, probably good for recognition
• states the team name, so it's distinct from Woo-wide tools
• does not use shorthand which makes it kind of disambiguous, and readable out loud 1:1 in plain English

But I have a doubt, whether it's not too long. Especially, when the package name adds up, and the name is used not only in package.json's devDependencies, but also in some other files, like configs, like:

• Some tags in .md files <woo-tracking-jsdoc></woo-tracking-jsdoc>
• Commands in package.json's scripts which to be fully consistent would be renamed to:

  "storybook": "woocommerce-grow-storybook",
  "storybook:build": "woocommerce-grow-storybook build",
  "storybook:deploy": "woocommerce-grow-storybook deploy",
  

• Config files as mentioned in #6 (comment) (however having that config file is a matter of another discussion)

Describe the solution you'd like

I see a few ways to go:

1. Don't make any hard rule and decide ad hoc for every case separately, the package name, the config references, the binaries' names, element names etc.
2. Make woocommerce-grow-{package-name} for every package reference
3. Use something shorter, like woo-grow-{package-name}
   1. Use it everywhere
   2. Use a long name for packages, a short name for any references

For woo-grow- I could list a few benefits

• shorter
• is well-coined shorthand
• Does not necessarily reference the WooCommerce product, but rather the Woo division. And we may have some tools not just for WooCommerce per see, but for some other needs. I cannot think of a good example now - maybe something like woo-grow-ping-porter CLI/slack command. Also Grow is not a part of WooCommerce plugin, but rather Woo as an organization.
• States a clear distinction between those packages and woocommerce packages. - "Is woocommerce-grow-up a WooCommerce's "grow-up" package, or WooCommerce Grow's up package?"

Unknowns

Out of bounds/rabbit holes

After discussion in this thread bout version in migrations https://a8c.slack.com/archives/CK365S85V/p1649061443268359 @JPry built a mod for Woo Release in order to replace the x.x.x string in the Migration classes.

Is your feature request related to a problem?

We need to handle manually DB Migration version changes

Describe the solution you'd like

Implement the mod built by @JPry in the Grow toolset in a way could be easily used by the team

Describe alternatives you've considered

Implement it directly in WR repo

Technical

It'd be the first composer package.

Acceptance criteria

• The DB Migration Version replacer could be loaded as a package in Composer
• The execution of the package replace successfully the x.x.x version.

Unknowns

The developer still needs to remember to execute this when doing the release so maybe it's possible to detect this in a more automatic way?

User story

As a developer, it would be good if the release process could be done easier and clearer.

Describe the solution you'd like

To make the new release more convenient, some automatic jobs were planned to be added to help the process:

1. 📌 Prepare a release content when a specific branch is created onto the target revision.
   • Fetch the automatically generated release notes provided by GitHub API.
   • Prepend the changelog content to CHANGELOG.md.
   • Bump the version in package.json and package-lock.json.
2. 📌 Based on the specific branch, create a release PR after a release content is finished.
   • Get the version from package.json to generate the PR title.
   • Add the release instruction in the description of the release PR.
3. 📌 Create a new release on GitHub after a release PR is approved.
   • Get the version from package.json to composite the release tag.
   • Get the respective content from CHANGELOG.md as the release notes.

With these workflows, the release process would be like:

1. When a package is ready to release, create a release branch onto trunk. For example, release/actions.
2. Check if the new changelog content and updated version are correct in the release PR.
   • If something needs to be revised, append the changes in this release PR.
3. Approve the release PR if it's all good.
   • Check if the corresponding release workflows are run successfully. For example, the workflow of creating a new release or updating version tags.
4. Merge the release PR.

Ref: p1689857980355099/1689849074.370359-slack-C0410KV3YLW

It seems we need to tweak the condition at
https://github.com/woocommerce/grow/blob/e0ee37b89343ba9b6b4d6db6088b3a3a4ecefe50/[…]-actions/actions/get-plugin-releases/src/get-plugin-releases.js
to the same we have for pushing to outputs:

release => (includeRC || !isRC(release)),

Then latest-versions woocommerce 5 --includePatches --includeRC would return ["7.9.0","7.9.0-rc.3","7.9.0-rc.2","7.8.2","7.8.1","7.8.0"]

UserDeveloper story

As a Grow developer, I'd like to run plugin the following compatibility checks across all our repos from a single composer package:

• WooCommerce minimum compatibility
• WooCommerce L-N support notice
• WordPress minimum compatibility
• PHP compatibility (planned)

Is your feature request related to a problem?

To enforce the L-N support policy, we need to run checks before initialising the plugin and run helpful notices or stop the execution of the plugin.

Describe the solution you'd like

Build a composer package with a CompatChecker class that runs all the compatibility checks based on the plugin header file. The compat-checker would be similar to the PluginValidator implemented in Google Listings and Ads.

The composer package can reside in a separate branch, and then be included in the individual plugins. We can use a GitHub action like this: https://github.com/marketplace/actions/push-git-subdirectory-as-branch to automatically deploy the changes into the packages/compat-checker folder into the separate branch.

Describe alternatives you've considered

The alternative would be individually implementing a PluginValidator class across all our plugins. This would be redundant.