[wp-trac] [WordPress Trac] #44492: Add new build:dev task which symlinks all files that can be symlinked

WordPress Trac noreply at wordpress.org
Tue Jul 3 16:39:12 UTC 2018


#44492: Add new build:dev task which symlinks all files that can be symlinked
------------------------------+---------------------
 Reporter:  omarreiss         |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  5.0
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  needs-testing     |     Focuses:
------------------------------+---------------------
Description changed by SergeyBiryukov:

Old description:

> This ticket introduces a new build task, meant specifically for
> development: `grunt build:dev`.
>
> The main difference with a regular build is that files are symlinked when
> possible instead of copied. This saves a lot of build time and means you
> don't have to rebuild anymore for most PHP changes. Since PHP files in
> `build/` are now symlinked to `src/`, changes are picked up directly.
>
> The new `grunt build:dev` task first checks if it can create a symlink on
> the system it runs on. If this is not the case, it will fallback to
> copying. `grunt watch` will also trigger `build:dev` instead of `build`
> now since it is only used in dev environments anyway.
>
> Files that are exempted from symlinking are the JS and CSS files, the
> themes, embed.php, formatting.php and version.php. This is because these
> are all transformed in some way when built. When someone adds a new file,
> they would still have to build to have it included.
>
> This ticket was inspired by issues that were raised after
> https://core.trac.wordpress.org/ticket/43055 got committed, mostly in the
> #core-committers channel on Slack. The main issues I've seen are the
> following:
> - Some people have lots of plugins in their `wp-content` folder. Building
> means copying all the plugin files over to `/build`. For some this
> crashes.
> - Developing with `grunt watch` can give issues on some development
> environments that run in VirtualBox (like VVV), where changes aren't
> being picked up. Having to rebuild manually after each change is a
> hassle.
> - XDebug breakpoints set in `src/` wouldn't be picked up.
>
> I believe these issues should mostly be mitigated or resolved through
> this ticket. I wasn't able to test so myself so I could use some help
> reviewing and confirming this is indeed a big improvement.

New description:

 This ticket introduces a new build task, meant specifically for
 development: `grunt build:dev`.

 The main difference with a regular build is that files are symlinked when
 possible instead of copied. This saves a lot of build time and means you
 don't have to rebuild anymore for most PHP changes. Since PHP files in
 `build/` are now symlinked to `src/`, changes are picked up directly.

 The new `grunt build:dev` task first checks if it can create a symlink on
 the system it runs on. If this is not the case, it will fallback to
 copying. `grunt watch` will also trigger `build:dev` instead of `build`
 now since it is only used in dev environments anyway.

 Files that are exempted from symlinking are the JS and CSS files, the
 themes, embed.php, formatting.php and version.php. This is because these
 are all transformed in some way when built. When someone adds a new file,
 they would still have to build to have it included.

 This ticket was inspired by issues that were raised after #43055 got
 committed, mostly in the #core-committers channel on Slack. The main
 issues I've seen are the following:
 - Some people have lots of plugins in their `wp-content` folder. Building
 means copying all the plugin files over to `/build`. For some this
 crashes.
 - Developing with `grunt watch` can give issues on some development
 environments that run in VirtualBox (like VVV), where changes aren't being
 picked up. Having to rebuild manually after each change is a hassle.
 - XDebug breakpoints set in `src/` wouldn't be picked up.

 I believe these issues should mostly be mitigated or resolved through this
 ticket. I wasn't able to test so myself so I could use some help reviewing
 and confirming this is indeed a big improvement.

--

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


More information about the wp-trac mailing list