[wp-trac] [WordPress Trac] #64393: Change how we include Gutenberg in Core

[WordPress Trac]

#64393: Change how we include Gutenberg in Core
------------------------------+--------------------
 Reporter:  youknowriad       |      Owner:  (none)
     Type:  task (blessed)    |     Status:  new
 Priority:  normal            |  Milestone:  7.0
Component:  Build/Test Tools  |    Version:
 Severity:  normal            |   Keywords:
  Focuses:                    |
------------------------------+--------------------
 When we setup the initial architecture and dependencies between Gutenberg
 and Core, Gutenberg was still considered a post content editor. It was
 setting at the same level of abstraction as TinyMCE. This assumption let
 to the use of npm packages to backport code from the Gutenberg repository
 into Core.

 The reality though is that this assumption is not valid for some time now:

  - Gutenberg includes a lot of iterations to PHP code base: endpoints,
 pages, menu items, block supports, block server side rendering, theme.json
 rendering
  - The Gutenberg repo outgrow the "post content" for some time now and it
 now powers multiple pages in wp-admin, multiple extensions to existing
 pages...

 During all that time, we "hacked" the process to accommodate some of this:

  - We have a lot of manual php backports
  - We do some automatic renames to php functions
  - We have npm packages that contain both php and JS
  and a lot more "hacks".

 In WordPress 7.0, we'll have a new addition to the Gutenberg repository
 that will force us to either add a new "hack" or reconsider the process.
 We'll have a new "font library" page added to wp-admin and the way it's
 being added is by using a new tool called `@wordpress/build` that
 automatically registers WP-Admin pages and uses "routes" to power these
 pages. This is a generalization of what we've been doing before for the
 site editor (and to some degree the post editor) to allow for easier
 iteration, scalability and extensibility.

 The build tool is likely to grow as well to absorb newer more and more
 extensibility points (or concepts) that don't exist today: Blocks,
 dashboard widget, field collections (these are just ideas at this point).

 The question becomes how do we backport these to Core (routes, generated
 pages, ...). I see two options in front of us:

  - Continue adhoc backports, copy the generated "php" code from the build
 folder of Gutenberg manually, sync the "routes" folder manually from
 Gutenberg and have some kind of build process on Core to recreate the same
 code. Very likely to create sync issues and more.
  - Reconsider how we "embed" Gutenberg into Core.

 I'm proposing that we take some time to explore the second option here and
 potentially simplify the whole process. What if we make Gutenberg a git
 submodule of WordPress Develop, ping the submodule to the Gutenberg branch
 that we want to include in Core (wp/* release branches) and update Core's
 build tooling to just call Gutenberg's (most of the time).

 I'm sure there are a lot more complexities to be discovered here. But I
 also see a lot of potential to both address the "routes" problem but also
 streamline some of the current php backports (not all of them).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64393>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform