Unreleased blazy dependency leads to unusable site

Created on 10 August 2023, over 1 year ago
Updated 15 August 2023, about 1 year ago

Problem/Motivation

Slick has been updated to Blazy 2.17 (via multiple commits, but #9d0411e on July 26th, 2023 is the one where the composer dependency has been changed, before that version has been released. As of August 10th, 2023, Blazy 2.17 still is in beta state. Due to this, updating Slick to 2.10@RC fails as Composer can't met the dependencies. This is even worse when Slick Views is installed as well.

I wouldn't create this issue if it was just to update for new features. But recently I started getting very strange PHP errors (via the orange PHP error screen) caused by Slick, which I can see being fixed in 2.10-rc1. This causes parts of my site to crash and render unusable, therefore the priority of critical.

Steps to reproduce

  • Create an empty Drupal 10.1 site via the composer recommended template
  • Install Slick 2.9 with matching Blazy and Slick Views versions.
  • Try to update Slick to 2.10@RC.

Proposed resolution

Don't add a dependency to an unreleased version!

Instead add a resolvable dependency (in this case blazy:2.17@beta) and create a follow-up task issue to update the constraint as soon as the dependency is released or at least gets a higher stability (aka RC) release.

💬 Support request
Status

Fixed

Version

2.0

Component

Code

Created by

🇦🇹Austria mvonfrie

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

Comments & Activities

  • Issue created by @mvonfrie
  • 🇮🇩Indonesia gausarts

    Noted. Thank you.

    Looks like the problem is the @RC, as also reported here:
    💬 Unresolved dependency on DB update with latest rc version Fixed

    AFAIK, requiring BETAs and RCs may need to correctly ask for the peak of the trees. In your case this will do:
    composer require drupal/slick_views:^2.8

    All dependencies will be in place up to Slick:2.10 an Blazy:2.17.
    Notice, I did NOT declare @RC, or alike.
    Machine like Composer is very smart to follow the declared dependencies. Human are not so, in this particular case, and may confuse Composer instead.

    Also, perhaps the safest is to always use regular production directive "prefer-stable": true, in your composer.json.
    Running the following will not download RCs, nor BETAs:
    composer update --with-dependencies -n --prefer-dist

    It will just stick the latest stable versions.

    I don't think, it is a bug at all.
    It works fine with the production mode above, or also fine with the correct require command.

    Anything I missed to know?

  • 🇦🇹Austria mvonfrie

    Basically I agree with you that only stable versions should be used, but that's not always possible.

    We had some problems which have been solved by 3367674 and as far as I remember from my colleagues other strange things as well, that's why we decided to switch to @dev until 2.10 gets released instead of applying the patch from that issue.

    Then yesterday we suddenly started getting the described errors which are fixed by #bfdf0d3 and even if that commit is included in the beta1 I decided to directly go to the RC1 as RC should be more stable than beta.

  • Status changed to Fixed about 1 year ago
  • 🇮🇩Indonesia gausarts

    Got it.

    Yes, depending on your composer setups, beyond me, you may want to use --prefer-source or --prefer-dist:

    To those in trouble, they won't work unless you configured your composer.json correctly to support the flags.
    No need to hack the module info.yml file, etc.

    Feel free to re-open if still an issue.

    Thanks.

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024