Local Environment: Replace custom setup logic with a Blueprints-based setup

[adamziel]

wp-now implements:

• Downloading and extracting zip files
• Download parallelization
• Using the requested PHP / WordPress version via CLI options
• Aims to have a JSON config at some point

These are Blueprints features. There's no need to re-implement them from scratch. Let's use and contribute to a common standard that other Playground projects will immediately benefit from.

For example, wp-now: download wordpress and sqlite in parallel wouldn't be needed if the assets were downloaded through a Blueprint.

cc @sejas @danielbachhuber @wojtekn @katinthehatsite

[danielbachhuber]

How do Blueprints work?

[adamziel]

I wrote up this documentation last week: https://wordpress.github.io/wordpress-playground/docs/blueprints-api/index

In short, it's a declarative data format where you communicate all the steps needed to set up a WordPress instance, and then the executor finds the optimal way of running these steps. They work in the browser and in Node.js.

For now this means downloading files in parallel with a concurrency limit. In the future it will involve flattening and parallelizing entire steps.

This Blueprint, for example, downloads a plugin and a theme in parallel and then installs both:

{
    "steps": [
        {
            "step": "installPlugin",
            "pluginZipFile": {
                "resource": "wordpress.org/plugins",
                "slug": "coblocks"
            }
        },
        {
            "step": "installTheme",
            "pluginZipFile": {
                "resource": "wordpress.org/themes",
                "slug": "pendant"
            }
        }
    ]
}

This one resolves the PHP and WordPress version to use:

{
    "preferredVersions": {
        "php": "7.4",
        "wp": "5.9"
    }
}

^ Blueprints will be merge-able, which means I'll be able to take a Blog Blueprint and a Woo store Blueprint and create a Woo Blog that uses the right PHP and WordPress versions.

[adamziel]

An update on that last point: WordPress/blueprints#49

[JUVOJustin]

I love the concept and do think blueprints are an awesome approach. For my specific use case of using the playground as a wp-env replacement, it would be great to have a way to pass a path to a blueprint for my local project as an optional parameter to wp-now. Maybe something like wp-now start -b './blueprint.json'. Some more specific thoughts:

• Ideally it would automatically use something like playground.blueprint.json by default and as fallback
• Some data might be provided twice like the php version and the wp version since they can be provided as parameters. Some have to take precedence

This allows to easily prepare various blueprints for various tests inside my ci. To me, it seems like a nice adoption of the committable wp-env.json file.

I love the idea of not only sharing the exact same setup with other developer inside a repo, but also provide example data through php snippets and also use the same instance for ci tests. So many possibilities 🤯