Implement CLI command to for a build process to transform modules into standalone plugins

[felixarntz]

Feature Description

Following #618 (comment), we now have an initial path forward for unbundling the Performance Lab plugin and creating standalone plugins from modules. While it is still being discussed whether we will publish all modules as standalone plugins or just a subset of them, we can definitely start working on the infrastructure changes needed.

For the purpose of this issue, let's simply start with one module, images/webp-uploads. This is just so that we can get started with one plugin. database/sqlite would be the other big priority to publish as standalone plugin, but that one is already available through the separate repo, so it's not a good idea to cover it here. In fact, it should be handle in a separate issue as bringing the codebase back into this monorepo will have its own little quirks to consider.

Requirements

• Add a config file (e.g. something like plugins.json) which contains a map of module directories and their associated standalone plugin configuration (for now probably just the WordPress.org plugin repository slug and intended version). The file should for now only contain the image/webp-uploads module. For example:

{
  "images/webp-uploads": {
    "slug": "webp-uploads",
    "version": "1.0.0"
  }
}

• Implement a new Node CLI command build-plugins in bin/commands that does the following:
  • Copy over all module directories based on the above config file (i.e. for now only image/webp-uploads) into a (git-ignored) build directory.
  • After copying over, replace each load.php file's module header with a corresponding plugin header:
    • Plugin Name and Plugin Description should use the module name and description respectively.
    • Plugin URI should point to the module's directory in this GitHub repository.
    • Text Domain should match the target plugin's slug.
    • Version should use the target version from the config file.
    • All other fields (requirements, author, license, ...) should match what is in the Performance Lab plugin's own plugin header.
  • Replace all usages of the 'performance-lab' text domain with the correct text domain for the individual plugin based on its slug (see above).

[joemcgill]

@felixarntz I think these requirements for a build process look pretty good to me. The main thing I think we should add here is that each built plugin should also include a README file (covered in #636, but should be thought of together with this task, I think). I think it would be easiest if we were to add module-specific readme's in folders with each module. Having a folder for each module would also allow us to add independent configuration files in each that would responsible for things like text-domains, plugin slugs, etc. if we wanted to keep those independent from a single plugins.js file as you're proposing here.

[felixarntz]

@joemcgill I think we can handle #635 and #636 separately. I'd prefer to iterate and we don't have to do all of that in one PR. Coming up with the readme content itself will be a bit of extra work, and that IMO shouldn't block us from working on this issue. #636 would include expanding the build process implemented in this issue here accordingly, to build the readme.txt files as well.

The changes proposed in this issue here can already work by themselves, so I don't see why we would need to combine both issues.

I think it would be easiest if we were to add module-specific readme's in folders with each module.

Agreed, we already have the module directories so we can just add the readme files to them. Though per my above reply I think we should work on that as part of #636.

Having a folder for each module would also allow us to add independent configuration files in each that would responsible for things like text-domains, plugin slugs, etc. if we wanted to keep those independent from a single plugins.js file as you're proposing here.

To me, a single plugins.js file is easier to manage, and it also provides a single point to see which modules are configured to be published as standalone. All we need to provide in this file is the map of module directory and plugin slug, so I don't think that justifies individual files for each module.

[mukeshpanchal27]

@felixarntz one question Do we need to use any Assets for the standalone plugin or not?

cc. @joemcgill

[mukeshpanchal27]

Additional question: Do we need can-load.php file in standalone plugin?