Skip to content

Conversation

@bacoords
Copy link
Contributor

@bacoords bacoords commented Dec 13, 2025

What?

Fixes external template variants not loading files in @wordpress/create-block

When using an external npm template (like @woocommerce/create-woo-extension) with the --variant flag, variant-specific template files were not being scaffolded, resulting in empty directories. This only occurred when pulling the templates from NPM, if you try to pull a template from your local machine (i.e. path/to/woocommerce/create-woo-extension), it doesn't have the same issue because the files are persistent on your machine.

Note: this PR was drafted with the help of Claude Code.

Related: #70855

Why?

External templates are downloaded to a temporary directory, loaded via require(), then the temp directory is immediately deleted. The bug occurred because:

  1. The main template files were processed while the temp directory existed
  2. Variant-specific template paths were stored but not processed
  3. The temp directory was cleaned up via rimraf()
  4. Later, when scaffolding tried to read variant files from those paths, the directories no longer existed

This made it impossible to use variants with external templates, severely limiting the extensibility of @wordpress/create-block.

How?

The fix ensures all variant template files are loaded before the temporary directory is deleted:

  1. templates.js - Modified configToTemplate() to eagerly process all variant template paths and return a variantTemplates object containing pre-loaded template content
  2. scaffold.js - Updated to use pre-processed variant templates when available, with fallback to legacy path-based loading for backward compatibility
  3. index.js - Fixed variant parameter passing in quick mode to ensure the variant name reaches the scaffold function

Testing Instructions

Test 1: External template with custom variant

  1. Run: npx path/to/local/gutenberg/packages/create-block -t @woocommerce/create-woo-extension --variant=sql-modification test-variant
  2. Verify the plugin directory is created with all files (should include composer.jsonincludes/Admin/Setup.phptests/Test.php, etc.)
  3. Check src/ directory contains variant-specific JS files

Before: Directory would be created but most files missing, variant directories empty
After: All 14 plugin template files and 2 block template files created correctly

Test 2: External template with default variant

  1. Run: npx path/to/local/gutenberg/packages/create-block -t @woocommerce/create-woo-extension test-default
  2. Verify all default template files are created
  3. Ensure no regression from the fix

Test 3: Built-in template variants (regression test)

  1. Run: npx path/to/local/gutenberg/packages/create-block -t es5 --variant=dynamic test-builtin
  2. Verify the dynamic variant files are created, including render.php
  3. Confirm built-in templates still work as expected

Testing Instructions for Keyboard

Not applicable - this is a CLI tool with no UI changes.

Screenshots or screencast

Before:

$ npx @wordpress/create-block -t @woocommerce/create-woo-extension --variant=sql-modification test
# Variant directories show as empty:
/tmp/wp-create-block-xxx/variants/sql-modification
[]
/tmp/wp-create-block-xxx/variants/sql-modification/src
[]

After:

$ npx @wordpress/create-block -t @woocommerce/create-woo-extension --variant=sql-modification test
# All variant files successfully scaffolded:
test/
├── composer.json
├── includes/Admin/Setup.php
├── languages/woo-plugin-setup.pot
├── src/index.js
├── src/index.scss
├── tests/Test.php
└── ... (14 total files)

@github-actions
Copy link

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

  • Required label: Any label starting with [Type].
  • Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

@github-actions
Copy link

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: bacoords <bacoords@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant