[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:  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 youknowriad):

 > First, the page-wp-admin.php file is being built into the wp-includes
 directory. This is the wrong context, it should be placed into wp-admin. I
 haven't audited all of the files being built and included after the
 changes here, but there are likely others.
 > Is it possible to direct these files to the right location? Or does the
 build package/routes require them to be shipped within wp-includes?

 If you think about this from how WP has always been organized, I'd agree
 with you but the important bit here is that we're introducing the idea of
 a build tool that generates code for us and for the ideal DevX we
 shouldn't care where the files are added or organized at all. The
 important part is that we should be able to load `build/build.php` and
 that's all we need for our routes, scripts, modules (and more later) to be
 registered properly at the right moment, with the right performance...
 Removing all boilerplate and often hard to pick integration points.

 So moving some parts of the build to a folder, and another to another
 folder is IMO the wrong solution, I wouldn't mind moving the build folder
 to `src/wp-build` or something but that feels like a bigger departure. We
 can think of this folder as the "includes" necessary to build and register
 WP-Admin pages but not necessary the admin pages themselves. The font-
 library.php file is still outside and it calls these includes.

 > function_exists

 I don't recall the details here, it's has been there for months now. My
 guess though is that these are not needed in any context because right now
 we have a unique "prefix" per wp-build usage and these just serve as extra
 safety. We can try removing them I think.

 > On the output php not matching expectations

 I think we can make a lot of improvements there, I'd love to have had help
 in Gutenberg when I was working on this but didn't get enough support at
 that point. What I would say though is that we should be looking and
 analyzing these files differently from the file we write manually. the
 same the output of webpack or esbuild or any build tool is not something
 you review manually when you use these in your own projects. For instance,
 we may have a rule to only use "const" in our JS files but the build tool
 might optimize and produce files that only use var or hoist or whatever.
 what I'm trying to say is that for generated files, the expectations are
 different because the goal is different. There's no expectation that one
 person is going to write and maintain all of this code manually (there is
 for templates) but the goal is to make the most optimized code first.

 That said, I do think there's a lot to improve there and please feel free
 to do so.

 > Next new concern I have is the way that scripts and styles are being
 registered and enqueued. In wp_font_library_wp_admin_enqueue_scripts(),
 the function returns early if the current page is not the expected font
 library. This means that WordPress is not always aware of the fact that
 the related scripts and styles are available.

 This is wrong, the scripts are always registered, they are only "enqueued"
 on the required pages.

 > What if someone wanted to extend one of these scripts, or load the font
 library experience within a custom admin screen? That's not possible given
 the current code. Perhaps the get_current_screen() results could be
 manipulated in some way to force this to run, but that's not ideal and
 would likely cause many side effects.

 Yes, this is not possible and not a goal we were building for. We want
 plugins to be able to add pages, remove pages, replace pages but not use
 the content of a page in another page.

 > Until now, JavaScript files have been maintained on the Gutenberg
 repository (because they are published to npm)

 This is not the reason for this, maybe it's something to clarify but for
 me the reason has always been and iteration on the gutenberg plugin,
 shipping quicker and Github over Trac. Integration over npm or git
 submodules or else is side effect. In fact I do recall early on 5.0 merge
 process that @azaozz has tried to change from npm to submodule (exactly
 like we did here) but that experiment concluded for a reason that I don't
 recall.

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