Problem/Motivation

We have been having a lot of problems with the introduction of DI into the current version of the code causing backwards incompatible code for both older versions of Drupal Core and modules that rely on instantiating custom instances of services, be it in contrib or the custom space.

Steps to reproduce

Proposed resolution

A possibility is to remove any suggestions that the CI makes to move towards DI style services.
Another possibility is to find a way to get a heads up when a contributed change is going to make a backwards incompatible change from version to version so we can can identify on how to proceed.

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork simplenews-3613461

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

generalredneck created an issue. See original summary.

generalredneck’s picture

generalredneck
him/his
Primary language English
Location Texas, USA 🇺🇸
commented
Title: Identify a way to check for backwards incompatible code » How to handle DI and affects to code (backwards incompatible breaking changes)

generalredneck opened merge request !112

generalredneck changed the visibility of the branch 3613461-how-to-handle to hidden.

generalredneck’s picture

generalredneck
him/his
Primary language English
Location Texas, USA 🇺🇸
commented

So this one is a little bit more of a challenge but I suspect that it's worth our time to possibly handle since just because we hide DI warnings in PHPStan doesn't mean people won't still use it. That said, it MIGHT be just fine to use DI in specific instances. We just need to make sure that the goal of "backwards compatibility" is maintained. Which may also mean we may want to include deprecations for the next major version of simplnews.

I'm not super sure there, especially given the tone of "minimally maintained" as described on the project page. That said, Roave/B ackwardCompatibilityCheck may be a valuable check!

adamps’s picture

adamps commented

The disadvantages: BC-breaks (code that sub-classes), adds a lot of boilerplate code.
The advantages: in theory someone might use it for some subtle testing, but noone seems to be asking.

Given this is an old, and declining project my feeling is that we don't necessarily need to bother. We can just hide this one in our phpstan config.