Composer cache is written to /app

[edmorley]

I'm currently auditing official/popular buildpacks for compatibility with potentially changing the build directory to /app in the future.

One of the potential source of problems for such a move, is that files written to /app (or to$HOME, which is /app during the build) will now be included in the slug, when previously they were not. As such, I'm checking what files are left behind by buildpacks in /app, using this buildpack which lists the contents of /app at build time:
https://github.com/edmorley/heroku-buildpack-list-app-dir

Testing the PHP getting started guide with the PHP buildpack + the above buildpack, I see that the Composer cache (~/.composer/cache) is being written to /app. Once the build directory is /app, this would cause the slug size to increase, potentially pushing apps closer to the limit. For the getting started guide this cache is only 28K, but I'm presuming that's low compared to a typical PHP app.

It seems there are few options:

1. If it's useful to actually keep the Composer cache (if it's not already being kept), move it to $CACHE_DIR instead
2. If it's not useful to keep the Composer cache, then either (a) try and have it be written to a directory under /tmp instead of $HOME, or else (b) delete it from $HOME at the end of the build

[dzuelke]

That cache directory isn't created by the PHP buildpack, but by the addition of your list-app-dir buildpack ;)

When the build system sources export before running your buildpack, this also invokes composer (because it adds $(composer config bin-dir) to $PATH), which creates this dummy directory, as $COMPOSER_HOME is now no longer set and thus defaults to $HOME/.composer.

The same happens on dyno boot (but obviously from a .profile.d/ script):

$ heroku run -- date\; ls -l --time-style=full-iso .composer/
Running date; ls -l --time-style=full-iso .composer/ on ⬢ [REDACTED]... up, run.6779 (Free)
Wed Feb  3 17:29:46 UTC 2021
total 4
drwx------ 4 u5931 dyno 4096 2021-02-03 17:29:45.955712928 +0000 cache

A potential workaround would be to preserve $COMPOSER_HOME in export, but that would mean that if people do very broken things in e.g. a "shell exec" buildpack, they might mess up their Composer cache. Although arguably they could do that in a million other ways, so maybe it's fine.

[edmorley]

Ah makes sense, thank you. Though this does mean with multi-buildpack (and not my test buildpack specifically), people will still end up with a slug that contains a .composer/cache due to the export script, when "build in /app" is made the default.