Prototype blueprint package format via Playground CLI #2029
Conversation
brandonpayton
added
[Type] Enhancement
brandonpayton
force-pushed
the
prototype-blueprint-package-format
branch
from
24d8dde to
f076cf2
Compare
|
I had some trouble getting the Blueprint schema generated, and it turned out that making FileTree have maybe-async values was breaking type extraction by It was possible to work around that conflict by making Now I am troubleshooting an issue with using blueprint asset resources at runtime. |
brandonpayton
force-pushed
the
prototype-blueprint-package-format
branch
from
f876acb to
752b7d0
Compare
| // @TODO: Consider validating whether this is a zip file? | ||
| const zipFileName = pluginData.name.split('/').pop() || 'plugin.zip'; | ||
| assetNiceName = zipNameToHumanName(zipFileName); | ||
| if (pluginData.name.endsWith('.php')) { |
There was a problem hiding this comment.
These changes now have their own PR: #2033
I'll leave this here for now because I'm using it to test, but it should be removed before merging this PR.
## Motivation for the change, related issues When testing #2029, I wanted to be able to install a plugin from a single PHP file and have it activated as part of the same step. This seemed reasonable, so I added support. ## Implementation details Prior to this PR, if the `installPlugin` step received a file resource it assumed it was a Zip file. This PR generally continues that practice but makes an exception for file names ending with a `.php` extension. File with names ending with `.php` are simply written to `wp-content/plugins/<filename>`. ## Testing Instructions (or ideally a Blueprint) CI - this PR adds a relevant unit test
Motivation for the change, related issues
Let's explore a simple format for packaging assets with a Blueprint that may use them.
Related to WordPress/blueprints-library#118
Implementation details
This PR mounts the contents of the package at
/internal/shared/blueprint-assets. It also creates dedicated Blueprint resources and references to use them, which will give us flexibility with how the assets are stored and accessed under the covers.As part of this PR, I'd also like to explore making directory-related resources async per file. Right now, it appears that resolving a directory resource is asynchronous once, but it requires returning the data of all children at once via a FileTree that looks like
Instead, it seems like we should only read file data when it is specifically looked up and used.
Testing Instructions (or ideally a Blueprint)
TBD