View in #core on Slack
@Matt_Robinson: Hi, anyone online to discuss core development?
Just looking through:
https://github.com/ClassicPress/wp-cms-experimental/pull/49
@Simone_Fioravanti: I’ve tested this locally and seems good.
@Matt_Robinson: Were the images all loading okay?
@Simone_Fioravanti: Don’t remember any issue about that.
@Matt_Robinson: Image files all seem to be included further down and lot looks just like branding changes.
Okay, after a fairly rapid scroll I can’t see any major issues, propose we merge.
@Simone_Fioravanti: Agree.
@Matt_Robinson: Okay, merged.
@Simone_Fioravanti: I’m wondering why the customizer menu link is gone…
@Matt_Robinson: Is that from the Admin menu?
@Simone_Fioravanti: Yes
@Matt_Robinson: Theme related - I’ve just dropped in TwentySeventeen and activated it and the Customizer link re-appears along with the Widgets and Menu options.
@Simone_Fioravanti: Ok, I’ve tested with Canuck CP and it was missing.
@Matt_Robinson: I can’t recall if Themes declare support for Customizer or declare that they don’t support it.
@Simone_Fioravanti: Don’t recall it too, but if TwentySeventeen works it’s good.
@Viktor: Sorry guys, very busy week.
I don’t think there’s a way to declare support for customizer. I think it may depend on “customize_register” hook.
@Matt_Robinson: We have merged PR47 in wp-cms-experimental. We need to consider the packages issue. Upstream created some standalone solutions to problems that surfaced in the development of the Block Editor, these are things like a packages version of autop. Some of these packages are now required elsewhere, for example Site Health and the Quick Edit box for Posts / Pages.
@Viktor: What you said about filters makes sense.
I got to run. School called, my daughter not feeling well. 
@Matt_Robinson: The inclusion of these packages is handled in the Gruntfile for local development and build / release. The question then is do we depend on these packages at all, do we include only what we need or do we include the whole lot (with maybe a filter so only what we need is loaded).
@Viktor: I think filter makes the most sense. But I’m open to other suggestions.
I think the key is to balance “bloat” and backporting process.
@Simone_Fioravanti: Hope we can strip out many but can’t give an opinion on this point, I’ve nearly zero experience with those packages and dependencies.
@Matt_Robinson: I have a better understanding now but still struggling to decide on the best way forward to balance bloat - namely loading files that are unused or removing these files from the distributed package that is ClassicPress and hoping that this doesn’t massively impact on backporting (as it is a package it should not as these are built when needed not really locally used files) and plugins / themes that use these (that should really package them themselves).
@Simone_Fioravanti: Think that if a plugins is using those it’s also using a lot of block stuff, so it will not work anyway.
@Matt_Robinson: To be honest I very much doubt it’s utilised but plugins much - at least at the moment.
@Simone_Fioravanti: Agree.
@Viktor: If we remove them now, can we add them back later? We can always make changes later based on user/developer feedback.
@Matt_Robinson: Not all of theme as some are needed in things like SiteHealth - but a good number can be removed.
Easy enough to add them back - just revert the commit (or partially revert) that removed them.
I’ll clean up what I’ve already been doing and get a PR ready for review by next week.
@Simone_Fioravanti: Great, ready to test!
@Viktor: That sounds good. We trust your judgement.
@Matt_Robinson: Great, leave that with me until next week then.
I was already very close so was a quick job:
https://github.com/ClassicPress/wp-cms-experimental/pull/50