Roots theme as a composer dep

archived 🗄
1

RE: Problems installing Compass (conflicting Ruby versions?) · Issue #53 · roots/trellis · GitHub

If you were to have your themes (Roots for example) as a separate repo, might as well make it a Composer package (with a type of wordpress-theme) and manage it through that.

@swalkinshaw Can you expand on this workflow you had in mind? My ideal workflow is where the theme-specific plugin dependencies are defined in a composer.json inside the theme which is maintained in a separate repository from bedrock-ansible and bedrock.

2

Define your theme as a composer package in Bedrock. Then create a new composer.json and use relative paths for the installer-paths inside your theme:

"extra": {
  "installer-paths": {
    "../../mu-plugins/{$name}/": ["type:wordpress-muplugin"],
    "../../plugins/{$name}/": ["type:wordpress-plugin"],
    "../../web/app/themes/{$name}/": ["type:wordpress-theme"]
},

You can also change the vendor path to match Bedrock’s with config:

  "config": {
    "preferred-install": "dist",
    "vendor-dir": "../../../../vendor"
  },

Although I’m not sure how I feel about that.

1 Like
3

That’s exactly what I meant. Your theme is a separate repo and it’s also a Composer package with its own composer.json file including dependencies.

In my opinion this should only be done in 2 cases:

  1. You know it’s going to be a parent theme used on a lot of sites.
  2. You want to share the same theme across a lot of sites AND a network install doesn’t make sense. Otherwise it can just be a theme in a WP repo like normal.

The key with Composer is that when you require a dependency, Composer will also install that package’s dependencies. Plugins defined in a theme package, for example, will get installed into the proper path in a Bedrock project. And since we include Composer autoload.php file, any other dependencies will work as they should in your theme as well.

The only problem with this workflow is during development you’ll probably have to figure out some solution like symlinking the theme into a WP project dir. Pointing your theme package to a local Git repo isn’t perfect because you’d have to do a commit AND run composer update in order to see the updates.

4

Hey thank you for responding guys! Sounds like it’s not as nice as easy as I was anticipating.

Yeah exactly, that kind of sucks the fun out of everything haha.

Well my thought process here is that bedrock and bedrock-ansible are pretty much their own projects. I usually clone bedrock and bedrock-ansible and actually track the upstream fairly occasionally.

I like the idea of having a 3 very clean commit histories

  • bedrock-ansible
  • just ops related stuff, perhaps grabbing stuff from the upstream as featured are added.
  • bedrock
  • just backend stuff, tracking upstream as fixes and improvements are added and such. Ideally my theme does not really know anything about bedrock anyway and I do not make any assumptions as to how the directory is laid out.
  • theme
  • might not even be roots and prolly gonna have multiple people actively editing this

Especially when I hire contractors that are not super duper skilled, it becomes kind of hard to manage when I have bedrock and the theme in the same repo with a million commits flying around.

I will play around with this and let you guys know what I find!

Thanks again!

5

Is the theme site specific though? Kind of like Roots is meant to be a starter theme, Bedrock is just a set of conventions and project structure. An actual WP site/project should be a repo that starts with Bedrock as its base, and includes a theme as well. Even if its a parent theme, as long as its specific for that project, it should be in the same repo.

You may want to have some actual fork/clone of Bedrock in a folder somewhere, but I’d only use that for upstream tracking purposes. You may then want to copy needed changes into actual other projects.