Do not just auto-generate entity mapping and other stateful information once because they change as the time passes. Also provide a command to keep those up to date - maybe verify them on the CI to check if they are outdated (like a new module was installed that provides X entity type => your current entity mapping is outdated).

For information, I was working on a custom kernel to dump everything: DI container with all the services (public, private), entity mapping, field definitions (to have information about dynamic properties etc..) and everything that are known runtime in Drupal.

The aim is to be able to analyse more things and in an easier way (we could get rid of loading all the services by ourself).
It could automatically dump everything when something changes (like with Symfony).

I already have a POC for the DI container (it was really really simple to do with a small custom kernel and a small custom DI dumper!)

Do you have any interest on this?

@mxr576 we wouldn't do anything. It's something folks would do and run on their own. As a helper utility. Which folks could run in their CI and diff changes.

@brambaud I do! It'd be interesting to see how you overcame the InstallerKernel, UpdateKernel, and the extended Drush ones. Or this intended to only swap the main index kernels

@mglaman For the moment the POC for the CI container is just a command line script replacing the main Drupal kernel.

For another purpose I also played by totally replacing the main kernel by changing the autoload (see https://github.com/ekino/drupal-debug#original-drupal-kernel-substitution for more information (I have to rework this lib from scratch because I let it rot for too long and the maintenance was too hard. I also have some ideas that require the same process so I don't know yet which one will come first)).