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

WordPress Trac noreply at wordpress.org
Mon Jan 12 21:55:55 UTC 2026


#64393: Change how we include Gutenberg in Core
------------------------------+--------------------------
 Reporter:  youknowriad       |       Owner:  youknowriad
     Type:  task (blessed)    |      Status:  reopened
 Priority:  high              |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  blocker           |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+--------------------------

Comment (by peterwilsoncc):

 Here's a summary of issues I am seeing (repeating myself so it's all in
 one comment):

 Technical:

 * Build now includes 17 package.json files
 * Build now includes 172 *.map files, most referencing files that don't
 exist
 * Building results in Gutenberg directory being dirty, preventing
 subsequent updates
 * install-changed doesn't include gutenberg hash in packagehash.txt,
 outdated dependencies aren't detected
 * changes are difficult to review, as a result it's easier for Gutenberg
 Experiments and other unintentional changes to end up in Core (as seen
 with Navigation block)
 * SVN ignore still hasn't been updated
 * Per
 [https://github.com/WordPress/gutenberg/pull/74490#issuecomment-3737458443
 GB#74490 (comment)] this will require more frequent changes to build tools
 in WP-Dev

 Administratively

 * The pull request was only allowed to sit for the holiday period.
 * Multiple commits have been made without review approvals
 * The initial commit was not tested, the build bug was available in the
 playground link

 > I think reverting creating more issues that it solves. This change is
 necessary for features slated for 7.0 and it's better to solve them way
 before alpha/beta than run to solve them at the last moment. -- Riad

 > Let's also see things from the other side a bit: it's a huge change that
 resolves a ton of friction on the Gutenberg dev side. I can't understate
 how much work and overhead it is every release to sync and merge the
 Gutenberg codebase into core. -- Ella

 @youknowriad, @ellatrix

 The issue I am seeing is that this is making it very difficult to do
 development confidently in the WordPress-Develop repository. While these
 changes remain in this repo in an incomplete state, it's not possible to
 know where an error is coming from.

 I know it's complex to import changes from the Gutenberg repository, this
 is demonstrating the past friction in updating them. By committing in a
 broken state, the ease for one set of developers is at the expense of
 blocking another set of developers.

 Blocking, or at least, significantly hindering developers is not worth the
 cost.

 > Worth noting that we're in the alpha stage and commits were made swiftly
 to resolve issues. It's really hard to make these changes without trying
 them.

 As mentioned above, this is introducing a significant hinderance for the
 development of code in WordPress-Develop.

 All of these changes could and SHOULD have been tested in a pull request.

 > This seems unrelated to how the code is integrated. cc @get_dave for
 awareness and potential follow-up in Gutenberg.

 This is incorrect, the package.json file is changed in
 [https://github.com/WordPress/wordpress-
 develop/blob/425bc36afc222a71a3c6038415ef71aa81f0ec83/tools/gutenberg
 /build-gutenberg.js#L108-L135 build-gutenberg.js#L108-L135].

 > Here’s a pragmatic proposal: what if we introduced a weekly cadence on
 this one in order to make it easier to find all the places that are broken
 but without obstructing everything in the meantime?

 @dmsnell I largely agree with this but am hesitant about committing then
 reverting in the event something breaks. The testing can be done on a
 feature branch so breakages should be detected in the branch on the PR.
 The actions generate the build, provide a playground link and other means
 of testing.

 I currently have a [https://github.com/peterwilsoncc/gutenberg-build/
 Gutenberg-Build repo] that I update each day. I'm happy to do the same for
 the feature branch so we can test more easily.

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


More information about the wp-trac mailing list