[wp-trac] [WordPress Trac] #47767: Simplify and backport the local environment

WordPress Trac noreply at wordpress.org
Thu Jul 25 06:35:21 UTC 2019


#47767: Simplify and backport the local environment
-------------------------------------+-----------------------
 Reporter:  pento                    |       Owner:  pento
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  5.3
Component:  Build/Test Tools         |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:
-------------------------------------+-----------------------

Comment (by pento):

 > 1. Documentation in the handbook for all of this functionality will go a
 long way.

 Agreed, we can realistically replace all of the
 [https://make.wordpress.org/core/handbook/tutorials/installing-a-local-
 server/ Handbook section on setting up a local environment].

 > 2. It would be nice if getting unit tests set up weren't left as an
 exercise for the reader. Perhaps this is best addressed with some nice
 documentation, as above.

 Yah, the unit test stuff is much more skeleton at the moment. It needs
 fleshing out, but it should be as simple as running `npm run test:php`.

 > 3. It feels awkward to me that `npm run dev` is an alias for `grunt
 build --dev` instead of `grunt watch --dev`, as I'm coming from Gutenberg
 where `npm run dev` watches for changes.

 Fair point. I don't think `npm run dev` is currently used anywhere, so we
 should be able to redefine it.

 > 4. I'd like if we didn't need to define `-next` commands in the
 `package.json`, so that running `npm run` would display the commands that
 can be run and nothing else. I assume this is a `dotenv-cli` limitation,
 though?

 Yah, that's a problem with `dotenv-cli`. It defines the environment
 variables in the child process that spawns. I'm happy to alter the pattern
 if anyone has better ideas, but I don't think we can avoid the concept of
 calling the `-next` scripts.

 ----

 While I'm writing, here's a handful of issues I've run into while working
 on this that still need addressing:

 - Docker caches the images it downloads pretty heavily, it won't check for
 new versions unless forced. We need an integrated-but-unobtrusive way to
 check for and download new images.
 - Downgrading to WordPress 3.7/3.8 silently fails. They require MySQL 5.6,
 which uses a different data file format to MySQL 5.7. As the MySQL image
 uses a persistent volume, it'll fail to load if the data files were
 created in the newer MySQL version.
 - PHP version and MySQL version should be defined through environment
 variables.
 - There are no official FPM builds of PHP 5.2 and 5.3. There are third
 party options, though. Same with MySQL 5.0 and 5.1.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47767#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list