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

WordPress Trac noreply at wordpress.org
Thu Mar 4 19:06:44 UTC 2021


#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 iandunn):

 > [know] what its original purpose was before removing it.

 AFAIK, before #43055
 [https://core.trac.wordpress.org/browser/trunk/Gruntfile.js?rev=43308
 `build/` was only necessary for production tasks like minification]. Most
 contribs ran from `src` locally, since it was simpler/faster.

 PHP tests used to run from `build`, but are now running from `src` again
 per #51734.

 This wouldn't remove any of the production functionality, it'd just
 simplify the dev workflow.
 [[br]]


 > ...any setups rely on [build/] currently? ...

 I'm not aware of any, but if there are, then it should be a straight-
 forward update. All of the files they'd need would still exist, just in a
 different location.
 [[br]]


 > 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?

 If someone clones the repo and runs the `watch` command, I think
 everything would still work as they expected. The only difference is that
 it'd ''also'' work if they ''didn't'' run it. We'd definitely want clear
 docs, though.

 The current direction has its own costs, like the unnecessary
 complexity/fragility and delays that tooling introduces.

 Most JS projects don't have a huge PHP component, but WordPress will for
 the foreseeable future. I feel like the needs of JS devs should be
 balanced with the needs of PHP devs.
 [[br]]


 > why do we need to commit built files to the repo?

 It makes it so that contributors don't need any tooling to get started,
 and don't need any when making changes to PHP or vanilla JS files.
 [[br]]


 > biggest hurdle for new contributors is getting their local environment
 set up

 I agree that's a problem too, but I don't think it makes this any less of
 a problem.

 Experienced contributors run into problems too,
 [https://core.trac.wordpress.org/query?type=defect+(bug)&component=Build%2FTest+Tools&time=05%2F23%2F2018..03%2F04%2F2021&col=id&col=summary&col=type&col=owner&col=status&col=priority&col=severity&col=resolution&col=focuses&desc=1&order=id
 the toolchain introduces a lot of failure points]. ''(Not all of those are
 directly related to this, but removing unnecessary complexity removes some
 of those failure points.)''

 Even when the tools work perfectly, they're still slow.

 ----

 If there's not a consensus on [comment:5 the zero-install approach],
 though, we could definitely do [comment:2 the copy-everything approach]
 for now, and leave zero-install for future discussions.

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


More information about the wp-trac mailing list