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/drup...
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.

There should definetely be an idea about sustainability and how make Drupal more eco-friendly in the core ideas issue queue - i'll check and create one if necessary.

But I agree this present issue is more of a task, a small - but meaningful 🙂 - addition to core.

So moving it back to core.

@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.

Thank you for the quick review. I agree ecofriendly is not the best name for this script.

Let's call it what it does: delete-tests-and-files.sh

MR updated and ready for review.

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

The intention for this script was to be run before "packaging for production" thus I thought it was relevant to remove the most files possible

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

I am curious what are good practices/standards regarding "unncessary" files in a web app.

Do we think we should keep them or do we try to minimize the size of Drupal?

One thing to consider is that some texts files are required by drupal-scaffold

  [RuntimeException]
  Scaffold file assets/scaffold/files/drupal.INSTALL.txt

Maybe the script should be adapt to delete files specifically, considering this type of execptions.

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.

Testing this script again, the Drupal projects weights 670Mb locally after a composer install.

Removing only the tests directories saves 62Mb (total disk usage: 602Mb).

Removing all text files saves 8Mb (total: 594Mb).

I suggest we keep all texts files because the gain is not so much and there are issues if some text files are not found (e.g. README with the help module, INSTALL.txt file with drupal-scaffold).

Updating code in attached MR.

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!

@AaronMcHale I totally agree. There is a broader topic of making Drupal more sustainable and this should be discussed within the community. Hoever I don't think this current issue is the best place to discuss such ideas. I see this script as a simple/specific addition to core.

I suggest we have conversation about sustainability within the dedicated project: https://www.drupal.org/project/sustainability →

I tagged the issue respectively for reference.

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.

@mglaman I wonder what you mean by "this won't work". Do you mean to run tests on production?

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.