Make bedrock a meta-package by extracting files into separate package

[heiglandreas]

• I've read the guidelines for Contributing to Roots Projects
• This request isn't a duplicate of an existing request
• This is not a personal support request that should be posted on the Roots Discourse community

Summary

By extracting the content of the config as well as the web folder into a separate package (i.e. bedrockfiles) that this package then requires, this package could be used to create a project but the files that currently then need to be added to version control of the newly created project could still then be handled as dependencies.

Motivation

Curently after calling composer create-project roots/bedrock I will have to add the files within the config-folder as well as the files within the web-folder to my version control. But those actually aren't files I need to or should edit. Usually those files are dependencies of my project that I don't want to (and probably shouldn't) edit. Why should I add them to my version-control then? Especially when one of the great advantages of bedrock is, that I don't need to add files to my version control that do not belong there.

But when I currently do exactly that (not adding them to VersionControl) I will not be able to retrieve a working installation using composer install as those few files are missing.

By extracting them to a separate package I would still have them installed on composer create-project but I would also get them installed on calling composer install. And a omposer update` would even update the files to the latest version.

Additional context

My main idea is to have a fully working WordPress with the least possible number of files. So for me the unique part of any WordPress installation usually is composer.json and composer.lock which contains all the plugins and WordPress as dependencies and then there is the theme folder. If the theme is a child theme, the parent theme is also a dependency within composer.json. Additionally there are some files for a docker-setup that usually are project specific (like the database-dump for dev and stage and such things). I'm currently thinking about moving them to a package as well.

This allows me to do the following to have a new (development) system up and running within seconds:

composer install
docker-compose up -d

OK: Perhaps in between one should copy the .env.dist to .env...

[Qrious]

This is a excellent idea, since now we need to port/reapply any upgrade fixes (i.e in case of vlucas/phpdotenv ^3 -> ^4) that you apply on this repo, due to how composer create-project works. It would be nice if this project would indeed only contain the composer.json/lock. This way those fixes don't need to be ported/reapplied by the whole community on every project (and we can rely on dependabot even more ;)).

[heiglandreas]

I've created a composer-plugin that could be used. I'm happy to hand that over ;-)

[Levdbas]

I like the idea! I dislike the manual updating of the config folder as well. But sometimes I do define my own constants in the application.php file. Like a google api code for instance or a license code that I do not want to include in the database. The values are then set in my .env file. So manually extending the application.php file in some kind of way that is part of your repository would be nice!

[aaemnnosttv]

I understand the motivation for this suggestion but in my opinion it's incompatible with the nature of the project: a boilerplate for WordPress projects. That's what makes Bedrock great is that it gives you a starting point to work from, but doesn't impose any limitations because there is no upgrade path and there can't really be one for Bedrock itself, because it's not a framework. I'm all in favor of making the default configuration in Bedrock more modular to make things easier to update for projects later on if you want to, but moving it into some official packages which are by definition uneditable is essentially turning Bedrock into a framework rather than a boilerplate.

I'm not saying it's a bad idea, just that I don't think that it fits Bedrock as a project. There's nothing stopping you from creating your own Bedrock-based framework/abstraction to make things easier for yourself and your projects though. By all means, do that (and maybe share what you made?) but let's not make Bedrock into a framework just to make things a little easier in one way and less flexible in another 🙂

[m-radzikowski]

Would be great to find the middle ground here. I too would like to just update dependencies by changing the version in composer.json instead of going over all files and patching them manually.

Moving files content to a separate package and just creating files with a simple require call to load them would make the committed files basically immutable when upgrading bedrock, but at the same time allow to override anything after the require call. Also, in case one overrides some options, it would be much simpler to distinguish between bedrock's config and own config.

[swalkinshaw]

I would be open to creating a new project which worked like this, but I highly doubt we'd change Bedrock itself to this model. It might even be possible to create the meta-package model and then generate the Bedrock boilerplate as it currently is, so we offer both alternatives.

I'll leave this issue open but it's not something we''re going to actively work on. We'd be happy to help out or discuss more if people are interesting in driving this forward.