Promote symfony/filesystem from dev-dependency to full dependency

I worry here about the crossover with the Drupal core filesystem service - we already provide copy, delete, mkdir, rmdir, tempnam and other methods, but Symfony also brings these in. Although, perhaps it is time to determine whether we should lean on Symfony components here and retire some of our custom code instead.

I'm not sure which automatic updates issue it was discussed in, but apparently the problem with replacing Drupal methods with the Symfony equivalent is lack of support for stream wrappers, so if we bring it in as-is, it can prevent adding new custom code but can't replace much or any existing code. Haven't looked at this myself though.

This is blocking #3364885: Allow themes to use a starterkit.yml file so it is easier to use the theme generator, so matching issue metadata.

@andy-blum Why a new issue? The existing issues have many more followers, and are likely to proceed faster. 😅

@catch & @longwave Related Automatic Updates issues:

1. #3326246: Add symfony/config to core's dependencies for package_manager
2. #3111008: Use native Symfony YamlFileLoader 👈 this is the most relevant one for this issue

Discussed this with @catch. The theme generator tool is a one-shot CLI script run by a developer, so can it just depend on drupal/core-dev? The command can check for the existence of the correct classes when it is run, and fail with a message telling the user that they have to install drupal/core-dev to be able to use it. We have some precedent in run-tests.sh which is shipped with core but that requires PHPUnit to be installed to work.

core-dev is not bundled into the tarballs which can be downloaded from Drupal core's project page - in fact there's no messaging on that page at all advocating for composer installation as a preferred method.

We really need to retire tarballs (except the ones that composer downloads) - automatic updates/package manager should make them redundant for pretty much any user.

The starterkit tool is grouped with recipes and distributions as a tool to reduce the barrier of entry for newer and less experienced developers. I don't believe requiring core-dev is in line with serving that audience, even if it's a relatively easy task to add/remove.

This is an interesting point but I'm not sure what I think about it - however does it need to actually block the other issues around this? Feels like we could change the level of the dependency independently of deciding to use it.

Personally, as a module and distribution profile maintainer who maintains a lot of scaffolding tools, I've had to add the symfony/filesystem and symfony/finder as not-dev dependencies myself to the projects I work on. In fact, I found it odd that Drupal Core didn't provide these as dependencies already. I would support bringing them in and with the acknowledgement that yes, it is confusing that there is both a Drupal filesystem service and a Symfony filesystem service,

I would support adding the dependency for all, and then separately follow-up for D11 to see how we could reduce and switch more things over to the Symfony version. But I don't think the latter should be a hard blocker to solving this for the starterkit generator, which we desperately need as an install profile with a "starterkit" base theme.

We do not want drupal/core-dev as a dependency for anything, we have encountered issues bringing that into consumer sites because of the composer/composer dependency.

The theme generator tool is a one-shot CLI script run by a developer, so can it just depend on drupal/core-dev?

IMO this is a bad idea. It creates bad developer experience for front-end developers who are not familiar with modern PHP / Composer (which there are many).

An example use case is a front-end developer who gets up and running using lando or DDEV, by running an automated script. Installing additional composer dependencies seems onerous after already having to run a command to generate the theme.

The question is do we expect this CLI tool to be able to run when you've used the core-recommended composer project. This template does not include dev dependencies (@longwave pointed this out to me). I think we do expect this tool to be available in this case. We could consider adding dev dependencies to core-recommended but this will get complex fast and there were reasons why we didn't include them.

I think given core-recommended exists and that drush uses both of the packages we want to add - the easy choice is to add the packages to the non dev dependencies.

We discussed this in Lille and @catch and @longwave agreed to add the components as regular dependencies.