Implement publishing workflow for standalone plugins that aren't modules

[felixarntz]

This issue is part 2/2 for setting up the new infrastructure for developing standalone plugins.

Requirements

This work should be implemented against a new feature/modules-to-plugins feature branch.

After #934 has been completed:

• The php-test-standalone-plugins.yml and deploy-standalone-plugins.yml workflows should be enhanced to also cover plugins found in the plugins directory (additionally to plugins in the modules directory, which need to be built first).
• Some key differences to look out for:
  • Plugins in the plugins folder can be assumed to truly be plugins (not modules). So they don't require a build process (at least not for now).
  • Modules still need to be built, the same way they are now.
  • In other words, the ready-to-deploy versions of modules continue to live in a folder within build, while plugins can be deployed directly from their folder within plugins.
• Both workflows should only act for plugins that are part of plugins.json.
• The npm run test-plugins command will likely need to be expanded to also cover plugins in the plugins folder (but only those that are in plugins.json).

[felixarntz]

Note: It doesn't really matter whether #654 or this issue is implemented first. To be able to test this one though, it probably makes most sense to work on #654 before.

[mukeshpanchal27]

@joemcgill @swissspidy @westonruter (cc. @felixarntz when you're back),

While working on the issue, I noticed that we missed specifying the version for plugins in #934. The issue requirements state that "plugins should have an array of plugin slugs," but we didn't mention the version for the plugins. When updating the deploy-standalone-plugins.yml workflow, I found that without the VERSION, the workflow fails and shows errors like svn: E155010: Path '/home/runner/svn-auto-sizes/tags/refs/pull/25' is not a directory. For more details, please check https://github.com/mukeshpanchal27/performance/actions/runs/7956545858/job/21717487210 where I initially checked it.

So, we must add the version for plugins as well. Could we use the same data structure as we use for modules?

{
  "modules": {
    "images/dominant-color-images": {
      "slug": "dominant-color-images",
      "version": "1.0.1"
    },
    "images/webp-uploads": {
      "slug": "webp-uploads",
      "version": "1.0.5"
    }
  },
"plugins": {
    "auto-sizes": {
      "slug": "auto-sizes",
      "version": "1.0.1"
    }
  }
}

Could you please review and share your thoughts so I can adjust the code and raise a PR for this issue?

[swissspidy]

Sure yeah submit a PR 👍

[joemcgill]

I think this is only necessary if we're planning on having the deployment process be responsible for handling version bumps for standalone plugins like we're currently doing for modules. The assumptions for this task were that we would not need a build process for deploying plugins, so we may need to modify the deployment script for standalone plugins instead.

[thelovekesh]

After #654 is integrated, will we still require the modules: {}? The "WIP" modules will resolve their version from the PL version, hence I believe we will just require the metadata for the standalone plugins from plugins.json after #654 is fixed.

[westonruter]

@thelovekesh great point. We should probably prioritize merging #1011 first some can simplify things by eliminating the logic for modules entirely.

[felixarntz]

@mukeshpanchal27 Replying to your question in #935 (comment), the reason this was defined as a list of plugin slugs is that the plugins would already be built, as @joemcgill mentioned. That means they already include their version in the plugin and readme headers.

Therefore to avoid (even more) duplication of the version number, I think it would be simpler to extract the version from the plugin or readme file rather than having to put it into plugins.json. The only reason the version is needed for modules is that those don't include the relevant header as it only gets inserted during the build process.

[felixarntz]

@thelovekesh Regarding your question in #935 (comment), this depends on whether we want to retain the ability to publish new features as modules first before publishing them as plugins or whether we're confident/comfortable with always publishing new features as plugins right away.

Additional discussion is required to make a decision on that question, so let's not change this yet until such a decision has been made. cc @westonruter

[felixarntz]

Fixed via #1000 🎉