What is going on latelly with v 12 receiving many breaking changes as minor fixes? Return types etc.?

[macropay-solutions]

We noticed lately that many breaking changes are finding their way as minor changes in version 12.
Can someone explain why?

And also, how are they caught so fast? Are there projects that don't use composer.lock? Or the composer update command is run frequently by many teams?

[mbabker]

The added types to the helper functions just prove that the Laravel framework can never be type safe. When the framework itself isn't respecting the documented contracts, and "major" ecosystem packages are breaking those same contracts, it just proves that at this point the dynamic type system of the PHP 5 era needs to be considered a first-class feature of Laravel, and that those looking for strongly typed functionality need to rely more on tooling like PHPStan and the Larastan plugin versus the framework itself.

The fact that these changes are breaking B/C for some is really a side effect of the duck-typing nature of Laravel and not necessarily a bug in the framework, minus the places in the framework where it's not respecting the contracts.

And also, how are they caught so fast? Are there projects that don't use composer.lock?

My small website has Renovate running pretty regularly. So for almost any non-major release in the Composer and NPM ecosystems, updates are being applied pretty quickly for me. So the combination of automated dependency management tooling and a majority of my own application's code being covered with automated tests means that site is being updated and deployed sometimes several times a day without me needing to sit there and manually validate everything.

[macropay-solutions]

Why run composer update and blindly trust laravel?
If there are no vulnerabilities, issues or new needs, you should not open the door wide open for new ones.
The MIT license gives them supreme power to f..k you and you can't do nothing about it if you blindly update.

[mbabker]

So I take it you fork and inline every vendor you consume, and never pull upstream updates? Are you also manually compiling PHP? How about resources like MySQL or Apache?

I'm not working on projects that require such tight scrutiny that essentially every commit needs a security audit, and if I were, there are very good odds I would not be consuming a lot of the stuff out there listed on Composer which has had no security screening and review and in a lot of cases is just a passion project. I also rely on the fact that upstream resources have their own test coverage and release with passing CI, meaning my tests should only fail when there is a regression in my interaction points with upstream.

[macropay-solutions]

So I take it you fork and inline every vendor you consume, and never pull upstream updates? Are you also manually compiling PHP? How about resources like MySQL or Apache?

When we run composer update we make a full regression testing before deploying yes. In payments we don't play with things like this.

[DanielCHood]

The problem with that Contract is that the return type isn't really part of the contract for Illuminate\Contracts\Session\Session, it is only a doc block. Therefore the Contract is saying that the method MUST exist and the return type SHOULD BE string. There's nothing insisting that the return type is string and therefore dependencies have been built on ?string instead of string. In this particular case, the contract is what needs updating, which is a problem throughout Laravel. Contracts need to be updated and decisions to be made whether to support backwards compatibility OR upgrade 'SHOULD' to 'MUST' by implementing the return type.

[mbabker]

In the absence of an engine-level type declaration, the doc block should be respected as the contract. It shouldn't matter that the runtime signature is effectively public function token(): mixed;, any implementations that violate the doc block should be considered broken and corrected.

The lack of engine-level type declarations makes it easier for these types of bugs to exist, but an implementation not respecting the documented contract should be considered broken and corrected. Unfortunately, we also live in a world where the contract is broken, and the stance of the contract "owner" is that downstream consumers are relying on undocumented behaviors, which effectively makes undocumented return types a feature of the framework.