Installing Drupal CMS with the zip file does not grab the latest version of dependencies

I'm certainly willing to rip out the composer.lock, but if we're going to do that, we should also remove vendor. A Composer-managed code base cannot operate properly without its lock file.

In other words, the zip file will shrink from being 70 MB and change, to probably less than 1. That's obviously good for a few reasons, but the main disadvantage is that, if the zip file has no dependencies installed, you MUST have Composer installed, or otherwise available (as via DDEV) to make Drupal CMS run at all.

The current state of the zip file is that you don't actually need Composer or DDEV; just a PHP-enabled web server. But if we remove the installed dependencies, this will no longer be the case. Bear in mind that core ships its zip files with dependencies fully installed, although they take more care to lock the dependencies to known versions since they have to be sensitive to API breaks and such.

I'm totally fine with doing this, to be clear, and I can see the advantages to not shipping dependencies...but I thought I would raise this point explicitly so you know what to expect. Are you sure you want to proceed? :)

This blocks Drupal CMS 1.0.0-rc2.

Another thing just occurred to me: if we do this, we might lose the ability to do installer cache pre-warming.

Why? Because pre-warming the installer cache requires doing an install, and that requires us to have all our dependencies installed.

So losing dependencies means that the installer's performance will go back to being pretty bad, although the static caching that landed in core for 11.1.0-rc1 should help mitigate that somewhat.

Again -- not saying we shouldn't do this. But it is something to consider.

Another thing just occurred to me: if we do this, we might lose the ability to do installer cache pre-warming.

It should be possible to to a full installation, and update the cache, then only add the relevant parts to the artefact. GitLab CI has a mechanism to enumerate the directories and/or files that will be contained in the artefact.

I don't really think I should be making the call on the approach, but to me it is a big problem that installing from the zip uses outdated dependencies. So perhaps we should reframe the issue to focus on that as a requirement and not specify a solution!

phenaproxima → credited rkoller → .

Well!

In a plot twist, 🐛 Remove .ddev directory from composer create-project Active forced our hand on this one. We cannot ship dependencies in the zip file now, or launch-drupal-cms.sh will fail. Why? Because ddev composer create freaks out if there is anything in the directory that it's trying to operate on. Without this MR, the zip file is full of extra files -- the web root, the dependencies, all that stuff.

So it's all gotta go. Since the zip file linked from https://new.drupal.org/drupal-cms/release-candidate is effectively broken without this fix (on a late Friday afternoon, no less!), I am making the executive decision to merge it.

Crediting @rkoller as he was quick to report this.