Add script to reduce disk usage by removing unnecessary files

Slack discussion: https://drupal.slack.com/archives/C06GX5T33/p1699958993938969

A test performed by jurgenhaas

# Step 1

composer install --no-interaction --no-progress --no-dev

# Step 2

composer config --no-plugins --no-interaction allow-plugins.drupal/core-vendor-hardening true
composer require --update-no-dev --no-interaction --no-progress drupal/core-vendor-hardening

# Step 3

wget https://github.com/MatthieuScarset/drupal-template/raw/10.x/scripts/drupal_thinner.sh
chmod +x drupal_thinner.sh
./drupal_thinner.sh

| Step | Vendor | Web |
| ---: | -----: | ---: |
| 1 | 73M | 207M |
| 2 | 71M | 207M |
| 3 | 68M | 118M |

Quite impressive to see a ±50% reduction in size!

IMO this is an ordinary feature request for Drupal Core. I don't think it has to pass the "ideas" phase.

@matthieuscarset, thanks for making this issue and providing a script. I have not tried the script or even read it carefully. What caught my eye is that the script is called "ecofriendly". In my experience that word is over used and too often misleading. I think we should just avoid any controversy about the word and use a descriptive name.

I like the idea of core tests not being installed when you create a project. They aren't included for composer packages in the vendor directory, so why should core's be included.

Renaming the issue title a bit as well.

# Delete README files.
find . -type f -name 'README*' -delete
find . -type f -name 'CHANGELOG*' -delete
# Delete patch records.
find . -type f -name 'PATCHES.txt' -delete

Wonder if these should be kept though? People may look into core for READMEs or the CHANGELOGs after an update.

When composer downloads a package, the tests were already removed (i.e. never packaged to begin with), thus reducing both the size of the zip file and the resulting extracted package. So, I'd say tests should be removed at the packaging stage of drupal core.

at the packaging stage of drupal core.

Actually at any package stage? (e.g. contrib).

The script would also clean NPM assets and vendor packages I would assume which can never by covered by packaging here on D.O

I might be wrong but i dont think Readme-like files are necessary on most prod environments.

Correct, unless you have the help module enabled and some contribs that try to render the readme files.

Just for the record, I recommended in Slack that an issue be opened in the ideas queue because to me it seemed like there was potential for wider discussion around this topic. Which for the record I fully support! But who's to say we can't find more than one possible solution to tackle this?

The advantage of the ideas queue is that it gives a space early iteration and feedback before any work begins, in my opinion that should be open to all kinds of ideas. It also helps to gain momentum for an idea, because people are more likely to be watching the ideas queue.

Having said that, I see some good work is already being done, and as I'm in favor of this, I'm not going to stand in the way of this progressing! So, carry on!

Instead of a script, what about using .gitattributes to exclude non-API test classes? You can't just purge all test files. Then KernelTestBase would break.

This won't work regardless demo_umami usage.

Do you mean to run tests on production?

No, but when would this script run? If it's not excluded from the packaged Drupal archive then we're still downloading the amount of files. If it's a post-install with Composer script, we're deleting the files and cannot run tests.

How is this intended to run? Inside packaging of a deployment artifact for end users? Then it could just be document for folks on how to minimize container images and other artifacts.

How is this intended to run? Inside packaging of a deployment artifact for end users? Then it could just be document for folks on how to minimize container images and other artifacts.

I think "just documenting" is not good enough, having good defaults is a thing we try to do everywhere in Drupal, so it should be the same for our sustainability efforts.

I think we could add this to core-recommended for example, since that is what sites use, and not what you'd use when trying to develop for drupal?

A much more aggressive solution could be https://github.com/dg/composer-cleaner. I tried this on a laravel project recently and that saved another ~50mb.

With Drupal CMS the impact would be even bigger with all the contrib files. I do think this is worth exploring more. Would there ever be a need to produce a developer version (with the extra code), or is that just what you would find in Git?

And agreed @borisson_ it is about setting up good defaults for when everyone works to download Drupal (or Drupal CMS).

How is this intended to run? Inside packaging of a deployment artifact for end users?

I have been thinking about this for a while, I'd like to think we can make this a dependency of core-recommended and not include it in core-dev. That way it can be a post-install script, however you are right there are some base classes we would need to keep around.