Roadmap 22.

[terabytesoftw]

• Update to the latest master branch.
• Add branch 22 to all yii2-extensions.
  • yii2-bootstrap5
  • yii2-debug
  • yii2-faker
  • yii2-gii
  • yii2-symfonymailer
  • yii2-mongodb
  • yii2-httpclient
  • yii2-twig
  • yii2-redis
  • yii2-authclient
  • yii2-elasticsearch
  • yii2-bootstrap4
  • yii2-bootstrap
  • yii2-jui
• Update templates yii2-app-basic, yii2-advanced and put them into operation with the 22 branch.
  • yii2-app-basic
• Apply Rector to clean up dead code from versions previous to PHP 8.2.
• Enable StyleCI for the 22 branch if possible.
• Integrate PHPStan for static analysis, configuring a baseline to allow progressive improvements over time.
• Once the branch is clean, we will make an initial release of the 22 branch along with all official extensions, providing a stable starting point without breaking changes.
• Gradually apply improvements and review pending PRs to determine what can be safely merged into 22.

[nadar]

good news! 🥳

[rob006]

Is there any explanation why there is 22.0 branch in this repo?

[rob006]

@terabytesoftw Actually, version in this changelog is something that I fixed (or broken - not sure at this point): ec57b0b

If next release will be 2.2.0, then why branch is named 22.0? Now if I want to install dev version of 2.2.0 I need to install 22.0.x-dev, because 2.2.x-dev is outdated (last change from May).

[terabytesoftw]

Yes, for now if you want to try the development branch it is with 22 certainly, but i will update that this week, that will not be a problem, now the idea is to release the development branch 2.2.0 an initial version equal to master, it only differs in the deprecated methods that were removed, the elimination of cubrid, xcache, and asset-packagist, which now you can install with php-forge/foxy, npm, now with the extensions i have tested and master can work with both branches, if we change the depreciated methods with the new ones, make explicit 2.0.53 and at least php 7.3, what do you think?

[samdark]

@rob006 the branch is named as such cause for some extensions there were 2.2 releases already and, in some cases, there were 3.x as well. So for versioning not to be super-confusing + to have an ability to still make major releases of extensions for 2.0 we add some space by using 22.x.x.

[rob006]

@samdark that explains why extensions use 22.x versioning. But it doesn't explain why development of 2.2.x release for framework uses 22.0 branch (instead of 2.2).

[samdark]

Consistency.

[max-s-lab]

I see that StyleCI is planned. Why not use PHP CS Fixer?

[terabytesoftw]

The framework already uses PHP-CS-Fixer, in Yii3 we use StyleCI, which is free for Open Source and is based on PHP-CS-Fixer with the same rules, the difference is that it has a bot that makes the corrections automatically in ci.

[max-s-lab]

Oh, I guess I didn't fully understand how StyleCI works. Thanks for the explanation.

[terabytesoftw]

btw thanks for the corrections of phpstan and phpdocs, now the static analysis is more great.

[xicond]

can we start to use declare(strict_types=1)

[max-s-lab]

I think there is nothing stopping us from doing this in new files.

For example, like here: #20528

[xicond]

I think there is nothing stopping us from doing this in new files.

But I suggest can do for all files, as 2.2 has no static analyses
even in v2.0, phpstan also only level 1

[terabytesoftw]

Yii2 does not use strict typing by design, since it relies on automatic type conversion. Adding declare(strict_types=1) to existing files would introduce BC breaks and could cause the framework to fail.

A safer approach would be to enable strict typing only in new files first. Over time, as we raise PHPStan level and improve type safety, we can evaluate if it is feasible to introduce strict typing more broadly without breaking compatibility.

[xicond]

It doesn't need the framework to define the type. it simply means, php to check for all variables type must match the expected data type, so it wont BC breaks except we add new type definition to existing expected variable

most it will be checking for existing, is php native type like, substr($str, strpos($str, '/')), this may raise error as we are not checking strpos for false return, as substr in php defined only accept int

<?php
declare(strict_types=1); // Strict mode enabled

$a = "hello"; // Fine, no type declaration needed for $a
$a = 10;      // Still fine, PHP is loosely typed for variables
$b = 5 + $a;  // Fine

// ... this code won't break just because $a and $b weren't declared as string or int.

but if defined expected variable, I guess we can start do casting to get more safety in v2.2

<?php
declare(strict_types=1);

function add_numbers(int $a, int $b): int {
    return $a + $b;
}

$x = "5";
$y = 10;

// This WILL BREAK and throw a TypeError because the function expects `int`,
// and strict mode prevents the coercion of the string "5" to the integer 5.
$result = add_numbers($x, $y); // 💥 Breaks!

As 2.2 is not officially release yet, we can scan all expected variable type

[rob006]

most it will be checking for existing, is php native type like, substr($str, strpos($str, '/')), this may raise error as we are not checking strpos for false return, as substr in php defined only accept int

It will require checking all data passed to framework code - strpos($str, '/') will fail if $str is a number, even if it worked fine before.