By ulandreman on

I'm trying to install the commerce module to my Drupal 9.1.2 site.

When I try to, however, composer alerts me (because my composer.json file is set to "minimum-stability": "stable", that commerce 2.23 requires /inline_entity_form ^1.0-rc6.  inline entity form is now at rc8.

What's the safest (i.e. least likely to crash my site) and wisest course of action I should take?
Reduce miminum-stability to RC?  Try commerce 1?  Other?

I assume others have come across this issue and had to deal with it.

Thanks!

⋅ Categories: Drupal 9.x

Comments

vm’s picture

vm commented

to avoid breaking a production site, you should have a site in -dev which is a duplicate of the current site. This allows you to test without issue. You can't use commerce 1.x on Drupal 8/9.

the following quoted from: https://www.drupal.org/node/3174472

When using a site with minimum stability stable, it is still possible to include non-stable dependencies by explicitly requiring the desired version in the top-level composer.json file using stability flags. For example:

$ composer require drupal/contrib:^1.0@beta

This would allow the beta or higher stabilities of the contrib project to be included; however, if the module had a dependency of its own that was not yet stable, the above command would fail due to the second-level dependency not meeting the minimum stability requirements. This situation can be resolved in a similar way, by requiring both the unstable contrib project and the unstable dependency:

mmjvb’s picture

mmjvb commented

and allowing other stability per extension as needed, as quoted above. Changing minimum-stability for all extensions increases the chance you get an undesired combination. Allow certain stability per extension, leave out the version constraint. Leave that to the parent extensions.

ulandreman’s picture

ulandreman commented

Thanks to everyone for your assistance.

I'm know and appreciate the benefits of having a development site to try things out and a production site that stays up for our visitors.

I also understand that using a module that hasn't been thoroughly tested and found to be stable opens the door to potential problems.

So, I'm still a bit unclear why or when a user or developer - unless the developer is willing to be experimental in nature or in an academic setting - would use a dependency that isn't stable yet.  It just seems that one is taking a risk that one doesn't need to.

Regardless, thanks again.

mmjvb’s picture

mmjvb commented

Similar to the usage of patches. Only use them when you need it. Contrary to patch releases, use them as soon as you can. That is why your version constraints should be like ~#.#.# to allow for patch releases.

vm’s picture

vm commented

in this case, you need to take that leap since commerce.module is dependent on inline entities. Why the commerce module developers would depend on a module that hasn't been released as 'stable' could be due to the fact that they didn't want to reinvent the wheel. Perhaps in Drupal 8/9 there are some things they are waiting on in core that will have an impact on the module. Perhaps they don't feel the module was tested enough with other combinations of modules etc. There is a multitude of reasons one may relay on a release marked alpha, beta, and RC. Note: modules marked as stale don't always mean 'fully tested' to the degree that it's been tested against every combination of modules in contrib and it certainly don't mean that bugs or security issues aren't found after the fact.

For a developer not to release means the code can't be tested in the aforementioned scenarios which would then mean that the module is never released at all. Considering the maintainers, the project that is using it etc, I venture you are fine since there are so many commerce module powered sites in the wild. These would be things that you balance against.