[wp-trac] [WordPress Trac] #51966: npm/grunt watch/build task names are inconsistent and unintuitive

[WordPress Trac]

#51966: npm/grunt watch/build task names are inconsistent and unintuitive
-----------------------------------+-------------------------------
 Reporter:  iandunn                |       Owner:  (none)
     Type:  enhancement            |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  Build/Test Tools       |     Version:  5.1
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:  javascript, docs
-----------------------------------+-------------------------------

Comment (by isabel_brison):

 > > ...any setups rely on [build/] currently? ...
 > I'm not aware of any, but if there are, then it should be a straight-
 forward update.

 So I poked around a bit and this is what I found:

 wp-env allows for specifying a local version of WP to build the dev
 environment from
 ([https://github.com/WordPress/gutenberg/blob/trunk/packages/env/README.md
 #local-wordpress-develop--current-directory-as-a-plugin]). The docs
 example uses build/, and in my testing I wasn't able to get it running
 from src/ at all. (It fails with `Error: 'wp-config.php' not found` even
 though I did have a `wp-config.php` in the src folder.)

 I'm sure this is fixable, but not sure how long it'll take to fix, so in
 the meantime it would be good to continue to provide a build/ folder. (wp-
 env is the only automated setup I know of that allows to build an
 environment from both Core and Gutenberg development directories, so
 pretty useful to debug cross-codebase issues.)

 Relatedly, the script that runs the Gutenberg e2e test suite on Core
 (https://github.com/WordPress/wordpress-
 develop/blob/master/tests/gutenberg/run.js) uses wp-env so also relies on
 build/ (at least until we can fix wp-env to work with src/)

 > > JS projects typically are structured ... Going in a completely
 different direction to this will be confusing to JS devs
 > Can you explain more about that?

 This is mostly my perception as a dev with more experience in JS/front end
 than PHP. The running from src/ thing did not seem obvious to me initially
 and I've since chatted with other JS contributors who were also surprised
 by this approach. Granted, it's easy enough to understand once the
 reasoning is explained, so if running from src/ is beneficial to PHP devs,
 let's do it! But we should be aware that some folks won't be expecting it
 and provide clear documentation about it.

 > Experienced contributors run into problems too
 As someone who has spent a lot of time debugging build issues, I'm very
 aware of this :( and agree reducing complexity is a good thing to do
 wherever possible!

 I think the copy-everything approach is the best solution for now, until
 we can make sure no one is relying on the build/ folder. Also so as to not
 blow out the initial scope of this ticket too much. Simplifying the build
 task names is already a great DX improvement so would be good to get that
 through soon, and then we can work on the zero-install approach as a
 follow up.

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