Scripts: Include variations paths in build #63098
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ockham
added
[Type] Enhancement
|
Size Change: -161 B (-0.01%) Total Size: 1.75 MB
ℹ️ View Unchanged
|
ockham
force-pushed
the
update/wp-scripts-build-to-include-variations-php-file
branch
2 times, most recently
from
daba1ca to
3b18531
Compare
|
Flaky tests detected in f6335fe. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/9941590851
|
|
To make this easier to test, we might want to consider fixing #63077 first. This will allow us to switch an existing Core block that currently uses Edit: It's a bit of a chicken-egg problem. Generally, unit-testing this is hard. Alternatively, we've considered using That script uses existing templates from the |
ockham
commented
Jul 10, 2024
ockham
commented
Jul 10, 2024
ockham
force-pushed
the
update/wp-scripts-build-to-include-variations-php-file
branch
from
3b18531 to
f6335fe
Compare
ockham
force-pushed
the
update/wp-scripts-build-to-include-variations-php-file
branch
from
f6335fe to
9c48c06
Compare
ockham
requested review from
gziolo,
ntwb,
nerrad,
ajitbohra and
ryanwelcher
as code owners
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
ockham
force-pushed
the
update/wp-scripts-build-to-include-variations-php-file
branch
from
d018c3e to
5fca20b
Compare
SantosGuillamot
approved these changes
Jul 17, 2024
There was a problem hiding this comment.
I've been testing it and everything seems to work as expected 🙂 I left a few comments with the goal of learning more than considering them issues.
I've been testing it in an external plugin pointing to this version of wp-scripts and this is what I tested:
- Using arrays in
variationskeep working as expected. - Using
variationsto point to a PHP file works as expected. I can see it include in thebuildfolder and variations appear in the editor inserter. - They work both with
buildandstart. - The
renderfile keeps working as expected. - I can include both a
renderfile and avariationsfile and they work as expected. - If I point a different property apart from
renderorvariationto a PHP file, it isn't built. - Other non-PHP files like
viewor CSS work as expected.
Comment on lines
356
to
+358
| function getRenderPropPaths() { | ||
| return getPhpFilePaths( [ 'render' ] ); | ||
| } |
There was a problem hiding this comment.
I assume we can't remove this function, right? Are these utils public? It seems getRenderPropPaths is not used anywhere internally.
There was a problem hiding this comment.
Good question. The function isn't exported from the @wordpress/scripts package, but it seems like we have some precedent of recommending importing functions from a subdirectory of that package, e.g. here:
const defaultConfig = require( '@wordpress/scripts/config/webpack.config' );
This is the reason why I didn't remove it, however slim chances are that someone actually does this with getRenderPropPaths.
However, your comment reminded me of the @wordpress/deprecated package. Maybe I'll use that to annotate the function as deprecated, which should pave the way for removing it at a later time 🤔
There was a problem hiding this comment.
Okay 🙂 I agree probably nobody is using getRenderPropPaths but the "compatibility" code is not complex either.
There was a problem hiding this comment.
Ah, it's a bit of a chicken-egg situation 😬 Seems like we can't require( '@wordpress/deprecated' ) in @wordpress/scripts, as the latter package is needed to build the former 😅
There was a problem hiding this comment.
I might just keep it as-is for now (to ensure I'm not breaking any obscure third-party thing that's relying on this).
There was a problem hiding this comment.
You should be able to remove getRenderPropPaths. We don't offer support for internal utils. I also don't expect this one would ever be necessary for 3rd party projects.
Overall, the idea always was that developers use mostly the scripts, but we started supporting also the default webpack config as it's where people tend to apply the changes the most often.
There was a problem hiding this comment.
Alright, I'll file a quick PR! Thank you for weighing in 😄
ockham
deleted the
update/wp-scripts-build-to-include-variations-php-file
branch
|
This is just a bit of a random thought but, is adding a field for each type of PHP file that might be needed the best path forward, instead of adding a more solution towards including any type of PHP file? {
"serverIncludes": [
"file:./variations.php",
"file:./components.php",
"file:./functions.php",
"..."
]
}I'm not sure how well adding individual fields per file type is going to scale if there are similar needs in the future. Again, just a random thought so happy to hear your opinions 🙂 |
Ah, TBH, that didn't really occur to me. I'm not sure we need (or should expect?) that many other server-side includes; plus it could be a bit tricky to have them depend on one another (e.g. The most compelling argument IMO is that for both In a similar vein, there's a defined requirement for AFAICT, the same cannot be said of more generic functions or components (as they aren't directly interfacing with the block). So for the time being, I don't see the need to change the established fields we're using for |
ockham
added a commit
that referenced
this pull request
Jul 17, 2024
Remove function `getRenderPropPaths()` from the `@wordpress/scripts` package. As of #63098, it is no longer used anywhere in Core. It has also never been part of the package's public interface. Co-authored-by: ockham <[email protected]> Co-authored-by: gziolo <[email protected]>
|
Makes sense. Thanks for the extra context, @ockham 🙂 |
carstingaxion
pushed a commit
to carstingaxion/gutenberg
that referenced
this pull request
Jul 18, 2024
If a `block.json`'s `variations` field is set to a (PHP) file name, include that file in the build, i.e. prefix its functions with `gutenberg_` and copy the resulting file to the `build/block-library/blocks/` directory. Note that this applies to third-party blocks, but not Core blocks. Making it work for Core blocks is a separate issue: WordPress#63077. Co-authored-by: ockham <[email protected]> Co-authored-by: SantosGuillamot <[email protected]>
carstingaxion
pushed a commit
to carstingaxion/gutenberg
that referenced
this pull request
Jul 18, 2024
Remove function `getRenderPropPaths()` from the `@wordpress/scripts` package. As of WordPress#63098, it is no longer used anywhere in Core. It has also never been part of the package's public interface. Co-authored-by: ockham <[email protected]> Co-authored-by: gziolo <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
If a
block.json'svariationsfield is set to a (PHP) file name, include that file in the build, i.e. prefix its functions withgutenberg_and copy the resulting file to thebuild/block-library/blocks/directory.Note that this applies to third-party blocks, but not Core blocks. Making it work for Core blocks is a separate issue: #63077.
Why?
As of #62092, it is possible to set the
variationsfield in a block'sblock.jsonfile to the name of a PHP file that generates the block's variations.How?
By extending the existing logic introduced for the
renderfield (by #43917 and #51162) to encompassvariations.Testing Instructions
block.jsonfile with avariationsfield that points to a PHP file.cd example-variations/../node_modules/.bin/wp-scripts build.src/variations.phphas been copied to thebuild/folder.variationsfield insrc/block.jsonto a variations array:"variations": [ { "name": "warning" } ].../node_modules/.bin/wp-scripts startto begin development in watch mode.variations.phpfile in thebuild/folder.variationsfield insrc/block.jsonback to"variations": "file:./variations.php".variations.phpfile should re-appear in thebuild/folder.Patch