[wp-trac] [WordPress Trac] #43055: Reorganize Core JS / introduce build step

[WordPress Trac]

#43055: Reorganize Core JS / introduce build step
------------------------------+-------------------------
 Reporter:  omarreiss         |       Owner:
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  5.0
Component:  Build/Test Tools  |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  dev-feedback      |     Focuses:  javascript
------------------------------+-------------------------

Comment (by pento):

 Nice work on this, @omarreiss. You've done a great job on this reorg, I
 think it has the potential to set WordPress up for a much nicer experience
 for contributors.

 I'd like to chat about why I think this change is a a good idea.

 == The Problems

 I've been reflecting on this issue since our discussions at WCUS, and I
 think it comes down to three issues that we're facing.

 1. ''The experience of contributing to WordPress is awful.'' There's a
 high barrier of entry just to get some sort of a local development install
 running, it takes way too much effort to maintain, and it's really hard to
 collaborate. Even if you manage to produce a patch, it feels like you're
 throwing it into the void.

 2. ''Adding a build step to the WordPress development flow is
 unavoidable.'' As we move towards our JS future, it's going to be
 necessary to make that move, Gutenberg is proving to be a useful testing
 ground for playing with build processes.

 3. ''JS build tools are nearly as bad as WordPress,'' in terms of the ease
 of someone being able to contribute to a JS project. They certainly don't
 tackle any of the hard problems, like setting up complete local dev
 environment. (If you're talking to an API to store your data, and not
 setting up a local copy of that API server and corresponding database,
 your dev environment is not complete.)

 == The Solutions

 With those problems in mind, I think there are a few promising options to
 solve them.

 On the topic of where to build things to, I find myself leaning towards
 option 1, though I can't entirely dismiss option 2. Option 3 is completely
 out, I don't believe there's anything but pain and maintenance headaches
 down the road of committing built files to the source repo. Option 2
 appeals, as the idea of allowing PHP changes without a build step is nice.
 That said, I also think it opens us up to a potentially confusing
 development experience, as we'll have committable PHP files living next to
 uncommittable JS files. Option 1 requires a build step for PHP changes,
 but it gives us the cleanest separation between development code and built
 code, even if the PHP is never really "built", as such.

 I have a love/hate relationship with VVV. I love it when it works, I hate
 whenever I have to setup a new computer, because the VVV part is so often
 the most painful. I believe we can do a lot better than that, and a lot
 better than what the current JS process looks like. Gutenberg currently
 makes limited use of Docker to provide a simple testing environment, I've
 been playing around with [https://github.com/WordPress/gutenberg/pull/4279
 expanding that] to include running PHPUnit tests, and generally having a
 full development environment created automatically. That PR is obviously a
 little rough around the edges, but I think it points in a good direction -
 we can easily automate setting up the entire development environment, and
 it's not difficult for us to detect when something is wrong, and give
 useful, contextual information for a contributor to get their development
 environment running again.

 Finally, (and this is more of a long term goal), I would be exceedingly
 happy if my development experience never involved opening a terminal
 window. App IDEs have been working on making their development experience
 not suck for many years, and they're a long way ahead of where the JS
 world is now. But there's a lot we can learn from them, and I think one of
 the most important lessons is that developing entirely in a GUI is an
 inherently better experience than typing a command into a terminal.

 == What's Next?

 Some of the stuff above is beyond this ticket, but it gives some context
 for why I think this is a necessary change, that on the face of it adds
 some complexity to the WordPress development experience, but actually sets
 us up for making the experience awesome.

 As @jorbin has mentioned, there are certainly some housekeeping issues to
 sort out before this can be committed. I agree that a make/core post is
 important, I'd be inclined to post it before the change is committed, not
 only so that people are prepared, but so we can get a wider audience on
 the proposal. This is a big change for WordPress development, it's
 appropriate that we should be able to make a convincing argument to the
 wider WordPress community before it lands.

 If build tools are relevant to your interest, I would very much like to
 see more activity on the Gutenberg tools. WordPress' future tools will be
 heavily influenced by what works in Gutenberg, so get in early if you want
 to shape what that's going to look like.

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