[wp-trac] [WordPress Trac] #43711: Let's create a standard development setup for WordPress core.

[WordPress Trac]

#43711: Let's create a standard development setup for WordPress core.
------------------------------+------------------------------
 Reporter:  omarreiss         |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  Awaiting Review
Component:  Build/Test Tools  |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:                    |     Focuses:
------------------------------+------------------------------

Comment (by jeremyfelt):

 From the original ticket description:

 > * the easiest possible development workflow: just download and boot.
 > * fast: reduce build and boot times to a minimum.
 > * reliable: it should just work.

 and

 > @pento noted that eventually he'd like this thing to be configurable and
 installable through a GUI in order to reduce the barrier of entry for new
 contributors to the absolute minimum.

 I think these are the right objectives for the future. I don't think these
 we can consider these complete while also requiring contributors to
 install Vagrant, VirtualBox, Docker, NPM, PHPUnit, and other command line
 tools to boot the box and get started.

 I think this happens when somebody creates a native app with a GUI that
 may run Docker or something else in the background, but shows no sign of
 that on the front. If we know people interested in tackling native app
 experiences in OSX and Windows, that would be super interesting.

 My (maybe slightly pessimistic) expectation of other solutions—new Vagrant
 VM, new Docker config, etc…—is that they'll all follow a similar path to
 VVV adoption over the last several years. More and more people use it,
 more and more people find bugs, a year or two later we have a bunch of the
 bugs figured out but it's still a pain for people to use in Windows.

 In the meantime, those who are frustrated with the new approach will
 filter off and install other tools that work for them (MAMP, Local, WPLib
 Box, etc…).

 One benefit that VVV has is that we've already ran into so many bugs at so
 many contributor days. And, as @TJNowell mentioned, VVV 3 will deliver a
 pre-provisioned Vagrant box that requires no time consuming process other
 than an initial download and future `vagrant box update`s. We've reached
 that point as a result of years of investment. We probably could have
 reached it sooner, but yeah - provisioning with bash scripts is ugly. :)

 Aside: I [https://jeremyfelt.com/2013/07/28/a-wordpress-core-vagrantfile/
 really wanted this as part of core] 5 years ago, but maintaining an open
 source dev environment project has altered my view quite a bit.

 And that all said, whichever route we go, I believe it is even more
 important that we continue to improve our documentation around
 contributing code. What the build process is, how to manage basic tasks
 with NPM, Grunt, Git, etc... I think that will have a larger impact
 overall.

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