Create a way for the launcher to "update" an existing Drupal CMS site

[phenaproxima]

There are times when Drupal CMS makes a change to its project template. Those kinds of changes are not updateable -- sites have to go change their composer.json manually (or at least by running some Composer commands).

For some of these things -- like when we introduced recipe unpacking support -- we really should be updating launcher-started sites too. That presents a problem, which is that launcher users cannot ever be expected to look at a command line. So it's up to the launcher to do it.

What we should do, I think, is introduce a concept of versions. Each version is just an integer. All launcher sites created up to this point are at version 0. A single version consists of a series of Composer commands. The current version should be stored in composer.json under extra.drupal-launcher.version.

When the launcher starts and Drupal CMS is already installed, it should automatically run whatever Composer commands are needed to bring its version up to the current one. The versions themselves, and the commands needed to bring an existing project to each version, should be hard-coded into the launcher (at least for now). The launcher should run these commands, then update the stored version in composer.json. This would allow us to ship updates not just to the launcher, but also to the project that the launcher manages.

If Drupal CMS is not installed when the launcher starts, then it creates the project and sets its version to whatever the highest defined version is.

[phenaproxima]

Thought about this a bit more and I have some implementation ideas.

What if we introduced the concept of a "project definition" which contains an array of install (initial setup) commands, and an array of updates (each of which is an array of commands to update the project from is initial state)?

Something like:

install:
  - [command]
  - [command]
  - [command]
update:
  -
    - [command]
    - [command]
  -
    - [command
    - [command]
  # ...

When setting up Drupal CMS for the first time, we only run the install commands, and record the version (which is update.length) in composer.json with composer config extra.drupal-launcher --merge --json '{"version": VERSION}'.

Then, when starting an existing site, we check the version (composer config extra.drupal-launcher version). Let's say we get back 3. That means, if update[VERSION + 1] exists, we run that set of update commands, along with all the subsequent command sets in update, and then store the new version in composer.json.

This would effectively allow us to automatically update the project as needed. It wouldn't be needed often, but it would be very handy when we do.

[phenaproxima]

This is blocked by #113.

[Sahilll10]

Hi @phenaproxima

Below is my concise understanding + proposed plan; please reply “go ahead” or assign me and I’ll open a small Draft PR

My Understanding:

Add a numeric extra.drupal-launcher.version to composer.json.

Introduce a hard-coded project definition in the launcher: install: [..] and update: [[..],[..],...] where each update[i] is the commands needed to go from version i-1 → i.

On launcher start: if no site → run install and set version = latest; if site exists → read version and run pending update arrays sequentially, updating composer.json after each successful step.

This is blocked until #113 (recording/reading version from composer.json) is resolved — I’ll coordinate with that issue.

Proposed implementation :

Hard-code a projectDefinition object in the launcher code with install and update arrays.

Launcher start flow:

1. Detect composer.json presence.

2. If missing → run install commands, then composer config extra.drupal-launcher --merge --json '{"version": LATEST}'.

3. If present → read composer config extra.drupal-launcher.version; run update[current+1]..update[LATEST] sequentially. After each update array succeeds, run composer config ... '{"version": NEW}'.

4. Execute Composer commands via the same child-process mechanism the launcher already uses (log stdout/stderr, show progress in UI).

Error handling: if an update step fails, stop, log the error, surface a clear UI message and leave the recorded version at the last successful step. Don’t auto-roll back composer changes (composer rollback is non-trivial); record failure metadata for debugging.

Tests: unit test the version-checking logic + an integration smoke test that simulates upgrade from v0→vN using no-op Composer commands (or a mocked composer wrapper).

If that plan looks good I’ll open the Draft PR (branch feat/update-versions) and begin with the core version-check + update runner and tests. Happy to adjust priorities or implementation details if you prefer a different approach.

Thanks — Sahil Kumar

[phenaproxima]

🤔 I'm not sure if you used AI to generate this proposal, but to be quite frank, it very much reads as if you did. To be specific, this seems like a rephrasing of my earlier comments in this issue.

I have access to AI tools as well, should I choose to use them, but I filed this issue without a PR because I am specifically looking for something beyond what AI tools can provide.

I'm happy to provide guidance to you on Drupal Slack (via DM), or we can set up a Zoom to discuss it, if you really want to take this on.

[Sahilll10]

Hi @phenaproxima

You’re right and I’m sorry, I used AI to draft the previous message. I’m new to contributing and really want to learn by doing .
Could you guide me briefly? I can either (a) open a tiny Draft PR to implement composer read/write for extra.drupal-launcher.version, or discuss over Slack/Zoom — whichever you prefer.

Thanks and Apology Once again.

[phenaproxima]

Thanks for your honest reply - I appreciate your forthrightness. I would be happy to guide you. Truth is, this feature will take a fairly significant amount of refactoring, so doing it in small bite-sized steps is a wise approach.

How about starting with this: can you create a PR that implements a getVersion() method that reads the version from composer.json? That would be a useful first step. I would respectfully ask that it be hand-coded, without relying on AI.

Thanks for taking this on; let me know if you have any questions.

[Sahilll10]

Apology for the late reply @phenaproxima Sir.
I have created a PR where I added a simple getVersion() method that reads a composer.json file and returns the version field.

Please review it and hence guide me ahead.

[Sahilll10]

Greetings @phenaproxima

I’ve opened a pull request with the updates - #174.
Please Let me know if there’s anything you’d like me to edit or improve.