Remove ExperienceDemoBuilder from the composer template

Created on 21 January 2025, about 12 hours ago

Problem/Motivation

See πŸ› Cannot download and install new modules using Project Browser (developer experience) Active and similar issues.

As implemented, it is not possible to update or remove the composer plugin with composer (and hence not with package_manager/automatic updates either), which means it will be impossible to fix bugs once it makes it into a release. Sites will eventually have the stable XB module enabled and then the plugin could continue to affect those, go out of date with the composer plugin API, essentially it will be un-upgradeable code in the code base indefinitely.

Steps to reproduce

Proposed resolution

Remove this from the project template, open a new issue to figure out how to safely provide an XB demo.

User interface changes

Data model changes

Release notes snippet

πŸ“Œ Task
Status

Active

Component

General

Created by

πŸ‡¬πŸ‡§United Kingdom catch

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @catch
  • πŸ‡ΊπŸ‡ΈUnited States phenaproxima Massachusetts

    Sites will eventually have the stable XB module enabled and then the plugin could continue to affect those, go out of date with the composer plugin API

    To clarify one part of this: the script specifically does nothing if you are updating XB from any version newer than 1.0.0-beta1 (the point at which a stable update path begins): https://git.drupalcode.org/project/drupal_cms/-/blob/1.x/project_templat...

    Also, it is merely a script, not a Composer plugin. So it's only using Composer's actual API. That said, Composer does play a little faster and looser with its API than core does, so the point about it being non-upgradable stands.

  • πŸ‡¬πŸ‡§United Kingdom catch
    To clarify one part of this: the script specifically does nothing if you are updating XB from any version newer than 1.0.0-beta1 (the point at which a stable update path begins):

    The script still runs when you have a stable release, it just short circuits. So if any of the composer or Symfony APIs it relies on change (e.g. a class being renamed and deprecated, then removed in a major release), it could very easily start throwing fatal errors.

    Also the first version of the script that I reviewed did not have that check. I pointed this out on the original issue, only a couple of days or so before the CMS 1.0 release - so there was a non-zero chance of it being released with 1.0 without that check being in place, then it would not have been possible to upgrade it to add the check.

  • First commit to issue fork.
  • πŸ‡ΊπŸ‡ΈUnited States thejimbirch Cape Cod, Massachusetts

    MR added which removes the script and the symlink, but leaves the recipe.

  • πŸ‡¬πŸ‡§United Kingdom catch

    I strongly think the recipe should be removed as well - the whole problem is trying to provide a demo of something that has no stable data model and therefore cannot be updated, within production sites that by definition need to be updated, and the composer script is just a symptom of trying to workaround that, but I can open another issue if necessary.

  • πŸ‡ΊπŸ‡ΈUnited States thejimbirch Cape Cod, Massachusetts

    Removed.

  • πŸ‡¬πŸ‡§United Kingdom catch

    MR is 100% removals but looks right to me.

    If someone figures out a safe way to provide a pre-beta xb demo that does not result in either un-updatable code or un-updateable sites then it could be added back, but I think it should only be included when all the various considerations have actually been fully thought through, solved, and tested, which will be easier to demonstrate from a clean slate.

Production build 0.71.5 2024