Solvedgutenberg @wordpress/env: A zero-config, self contained local WordPress environment for development and testing.
✔️Accepted Answer
We've iterated a lot on @wordpress/env
these past few weeks and I think we're now at the point where we can close this issue and use smaller more focused issues and bug reports for any further work. The [Package] Env
label tracks this.
Thanks everyone!
Other Answers:
Support running in Core, wordpress-develop, with a --dev flag.
Was thinking a bit about this. How about, instead of a --dev
flag, we expand on the .wp-env.json
config file so that wp-env
is a tool which can glue together arbitrary combinations of core, plugins and themes?
Some examples of different .wp-env.json
configs:
- Run the current directory as a plugin installed onto the latest
trunk
version of WordPress. Plugin build files must built manually e.g. by runningnpm run dev
. Use cases: Plugin (incl. Gutenberg) development
{
"core": "WordPress/wordpress#master",
"plugins": [ "." ]
}
- Run a few local plugins and themes installed onto the latest production version of WordPress that the
wordpress
Dockerfile uses. Plugin or theme build files must be built manually e.g. by runningnpm run dev
. Use cases: Plugin (incl. Gutenberg) development, Theme development, QA
{
"core": null,
"plugins": [ "~/projects/gutenberg", "~/projects/advanced-custom-fields" ],
"themes": [ "~/projects/twentytwenty" ]
}
- Run a few local plugins and themes installed onto an older latest production version of WordPress. Plugin or theme build files must be built manually e.g. by running
npm run dev
. Use cases: Testing, QA
{
"core": "WordPress/wordpress#5.0",
"plugins": [ "~/projects/gutenberg", "~/projects/advanced-custom-fields" ],
"themes": [ "~/projects/twentytwenty" ]
}
- Run a local plugin installed onto a local development version of WordPress. Core build files must be built manually e.g. by running
grunt watch
. Plugin build files must be built manually by running e.g.npm run dev
. Use cases: Core development, Plugin (incl. Gutenberg) development
{
"core": "~/projects/wordpress-develop/build",
"plugins": [ "~/projects/gutenberg" ]
}
Similar to the dependencies field in npm-package.json, we can support all sorts of different paths and URLs in core
, plugins
and themes
:
- An absolute path:
/path/to/gutenberg
- A relative path:
../gutenberg
- A GitHub URL:
WordPress/gutenberg#master
- A Git URL:
git://develop.git.wordpress.org#master
- A SVN URL:
svn://plugins.svn.wordpress.org/advanced-custom-fields/tags/5.8.7/
- A ZIP or Tarball:
https://wordpress.org/wordpress-5.3.1-RC2.zip
When a local path is specified, it is mounted into the Docker container as-is. When a remote path is specified, it is cloned or downloaded into a temporary directory (maybe: ~/.wp-env
) and then mounted. When a remote path is a GitHub or Git URL and has been cloned before, a git pull
is performed.
SVN, ZIP and Tarball URLs are a nice-to-have and can be implemented further down the track.
What do you think?
I put up a PR which could add support for a .wpenv file as we discussed: #18121. Open to feedback!
#17668 was merged as the base for a new WordPress local environment CLI tool for development and testing that avoids the pitfalls of previous iterations.
Previous approaches were slow, required too much configuration, and/or did not work on certain machines/versions of Docker Engine.
wp-env
will be a zero config tool for developing plugins, themes, or Core, and it will replacenpm run env
. Its goal is WordPress development in general, but it doesn't achieve it at the cost of burdening plugin or Gutenberg developers with various configs, commands, and options. It will automatically infer what the user needs from the contents of the folder it is running on and act accordingly.The base PR supports plugin development, which includes Gutenberg. Here are the next steps needed to make this tool accessible to all types of WordPress developers:
--help
output.@wordpress/scripts
'snpm run env
withwp-env
.