yiisoft / yii-core Goto Github PK

DynamicModel::addRule() should be same like Rule in Model::rules()

// DynamicModel
    public function addRule($attributes, $validator, $options = [])
    {
        $validators = $this->getValidators();
        $validators->append(Validator::createValidator($validator, $this, (array) $attributes, $options));
        return $this;
    }

vs

//Model
function rules() {
 return [[['address'], 'string', 'max' => 200],];
}

now, it is required to use array_slice($rule, 2) to extract $options.

REF #https://github.com/yiisoft/yii2/issues/16027

Hello!
I try to override runAction in my module but it not works.
Here is a call trace:

Bug or feature?

What steps will reproduce the problem?

Constants are used in Yii as some kind of static configuration and should be avoided if possible in a simple way.

Here's a list of the current constants:

/*
    Used in the debug module, can be replaced with $_SERVER['REQUEST_TIME_FLOAT']
    Note that this is not an argument to use $_SERVER directly.
*/
defined('YII_BEGIN_TIME') or define('YII_BEGIN_TIME', microtime(true));
/*
    Used in the classmap, this could be phased out when bootstrap becomes the way to go. (Bootstrap can create a classmap for Yii classes. 
    Also used in the logger to clean up backtraces. 
defined('YII2_PATH') or define('YII2_PATH', __DIR__);
defined('YII_DEBUG') or define('YII_DEBUG', false);
/*
    Used only to define other globals: YII_ENV_PROD, YII_ENV_DEV, YII_ENV_TEST.
*/
defined('YII_ENV') or define('YII_ENV', 'prod');
/*
    Used to prevent migrate/fresh command.
*/
defined('YII_ENV_PROD') or define('YII_ENV_PROD', YII_ENV === 'prod');

defined('YII_ENV_DEV') or define('YII_ENV_DEV', YII_ENV === 'dev');
/*
    Used to regenerate session id after switching identity; one could argue this should always be done regardless of this global.
*/
defined('YII_ENV_TEST') or define('YII_ENV_TEST', YII_ENV === 'test');
/*
    Only used in registerErrorHandler, which also uses the configuration array. (So it might as well be enabled / disabled via that configuration array)
*/
defined('YII_ENABLE_ERROR_HANDLER') or define('YII_ENABLE_ERROR_HANDLER', true);

While defining constants is not considered a side-effects according to PSR-1, it still leads to strange behavior in the entry script due to autoloading. When using autoloading it is not always obvious when a class file gets parsed and thus the status of these constants is not always clear. (We can't override them after they've been defined).

Motivation

If there are simple scoped or built-in alternatives to global constants I feel they should be preferred. One downside of constants is that they are global in nature and therefore any change to them breaks backwards compatibility.
If we choose to try and move away from these constants 2.1 would be the time to do it.

Now that modules have tree traversal we should add context to resolveCallableDependencies.

What steps will reproduce the problem?

Application has User component.
Module A has User component.

Somewhere in Module A try to use resolveCallableDependencies on something that requires a User component.

What is the DESIRED result?

I'd love to get my modules' User component.

What do you get instead?

The applications' User component.

Additional info

Basically the way \Yii::$app is used in the container is as a preferred ServiceLocator. Instead we could support passing in any ServiceLocator as a context.

Current signature:

public function resolveCallableDependencies(callable $callback, $params = [])

Proposed signature:

public function resolveCallableDependencies(callable $callback, $params = [], ServiceLocator $context = null)

Temporary backwards compatible implementation:

public function resolveCallableDependencies(callable $callback, $params = [], ServiceLocator $context = null) {
if (!isset($context)) {
    $context = \Yii::$app;
}

At some point we should then remove the default and always require explicit context (thus removing the access to the global).

What's the problem?

Currently IdentityInterface contains both methods to get an identity and methods which belong to the identity instance. While it is OK in context of Active Record it is an obstacle for implementing repository and entity separated.

What is the expected result?

Being able to separately implement repository which responsibility is to get an instance of identity, and an entity which actually holds the data.

What do you get instead?

A single interface forces us to implement everything in a single class.

Additional info

That's how new interfaces would look like:

interface IdentityInterface
{
    public function getId();
    public function getAuthKey();
    public function validateAuthKey($authKey);
}

interface IndentityRepositoryInterface
{
    public static function findIdentity($id);
    public static function findIdentityByAccessToken($token, $type = null);
}

At the present state Event::$data is populated by parameters stored along with event handler, e.g. specified at Component::on()/Event:on() invocation.
This produces a wierd behavior, when event's internal data is overridden from outside, while common developer's expectation is quite an opposite. See #12766, #15227 for instance.

As far as I remember specification of the data for the handler was introduced to facilitate re-usage of the same handler with different parameters. However, I suggest that such use case should be handled in other way. For example a specific callback wrapper object may be used instead.

Most existsing 3rd party event implementations as well as PSR Events Draft also treat event's data as an internal field, specified at the event triggering level, instead of being varying by handler.

I would suggets returning to original Yii 1.x logic here at 2.1 milestone.

https://github.com/yiisoft/yii2/blob/master/framework/console/controllers/FixtureController.php#L105 example

    public function actionLoad(...$fixturesInput)
    {
    }

This issue has originally been reported by @schmunk42 at yiisoft/yii-base-web#4.
Moved here by @cebe.

We found it pretty handy to have the ability to get the (merged) app-config and environment from a command.

    /**
     * Shows application configuration
     * Note that this action shows console configuration.
     *
     * @param null $key configuration section
     */
    public function actionConfig($key = null)
    {
        // get config from global variable (TODO)
        $data = $GLOBALS['config'];
        if ($key) {
            $keys = explode('.', $key);
            if (isset($keys[0])) {
                $data = $GLOBALS['config'][$keys[0]];
            }
            if (isset($keys[1])) {
                $data = $GLOBALS['config'][$keys[0]][$keys[1]];
            }
        }
        $this->stdout(VarDumper::dumpAsString($data));
    }

    /**
     * Shows application environment variables.
     */
    public function actionEnv()
    {
        $env = $_ENV;
        ksort($env);
        $this->stdout(VarDumper::dumpAsString($env));
    }

Unfortunately it's a bit hacky in the config part, but this might be an issue for the core.

Currently we have 2 kinds of magic getters:

1. Simple (implemented in yii\base\Component)
2. ActiveQuery (implemented in yii\db\BaseActiveRecord)

I propose replacing (2) with a generic implementation for resolvable getters. Resolvable getters would be defined as anything that describes an operation that you might want to change before executing.
When using it as a magic getter it would then get resolved with the default settings.
This is 100% analogous to how it currently works for ActiveQueryInterface.

public function __get($name) 
{
    ...
    if (array_key_exists($this->_resolved, $name)) {
        return $this->name;
    }

        $getter = 'get' . $name;
        if (method_exists($this, $getter)) {
            // read property, e.g. getName()
            $value = $this->$getter();
        } else {
            // behavior property
            $this->ensureBehaviors();
            foreach ($this->_behaviors as $behavior) {
                if ($behavior->canGetProperty($name)) {
                    $result = $behavior->$name;
                    break;
                }
            }
        }
        return $this->resolve($name, $result);
}

/**
* Allows child classes who override __get to reuse the resolving part.
*/
protected function resolve(string $name, $resolvable) 
{
    if ($resolvable instanceof Resolvable) {
        $this->_resolved[$name] = $resolvable = $resolvable->resolve($name, $this);
    }
    return $resolvable;
}

Note in the above example error handling is missing (unknown or write-only properties). But the idea is clear.
BaseActiveRecord should then be changed to use this generic approach.

@mikehaertl commented on Mar 7, 2018, 11:28 AM UTC:

I have to come back to my closed issue #12021. It seems that this is still not fixed in Yii 2.1.

My description and use case there is still valid.

The outcome of #12021 was, that this should be implemented via a trait. But it seems this never happened in 2.1.

tl;dr: I want to use the magic getter/setter methods from yii\base\BaseObject to be available in my custom classes. But I don't want that this changes PHP's default behavior, where you can also set undefined properties on a class.

<?php
class X
{
}

$x = new X;
$x->demo = 'x';   // No error, PHP allows to have dynamic properties

echo $x->wtf;  // Error, because 'wtf' was not set yet.

Yii changes this default behavior of PHP:

<?php
class X extends yii\base\BaseObject
{
}

$x = new X;

// This will throw an error:
$x->demo = 'x';

This issue was moved by samdark from yiisoft/yii2#15845.

Since this version will require php7.1 I think it should use a more strict typecasting on the class/interaces declarations.

For example at yii\base\Controller::createAction() the signature is

public function createAction($id)

I think it would be better if its changed to

public function createAction(string $id): ?Action

The same can apply to several other methods which might benefit from php7.1 typecasting.

Couple proposals for framework developers. It would be nice if you could follow best practices when writing Git comments: https://chris.beams.io/posts/git-commit/
In Russian: https://habr.com/post/416887/

Also, consider using this format for the project change log: https://keepachangelog.com/en/1.0.0/

Thanks.

i want to setup some aliases in the app config such as an uploads directory:
'aliases' => [
'@uploadsurl' => '@web/uploads'
],

however this fails because @web is unavailable in the config stage which sucks. @web and @webroot shouldn't need to wait until Request to be defined. are they not extremely independent values?

For 2.1 some cleanup can be done in the ErrorHandler component.

• Remove HHVM code (#14280)
• Check if we can remove handleFatalError, since they are now thrown instead.
• (re)Consider using some library like whoops (I know this has been previously considered in #297, but it makes sense to reconsider this from time to time)

https://github.com/yiisoft/yii2/blob/cf1bb804831cfb90256328eb302d27c1a4858d99/framework/base/DynamicModel.php#L120

this way the attribute can not be set anymore with which unset would be equal to undefineAttribute().

should be $this->_attributes[$name] = null; instead

The ROADMAP.md says that LTS will be announced for v4.0 in 2018.
Are there already some details around? I'm working with Yii2 for over a year now and tried to convince my co-developers to use it for new projects. To avoid risks and future problems (like AngularJS / Angular had) some sort of LTS would be essential. Can you provide some infos at this point?

@rhertogh commented on Oct 11, 2018, 6:37 PM UTC:

What steps will reproduce the problem?

#15847 and #15202

In our development flow we have 4 different environments, 'dev', 'test', 'staging' and 'production'.
In our deployment script we call yii migrate but when the migration fails on the 'test' environment the deployment script continues because no exception is thrown.

What is the expected result?

An exception should be thrown to abort the deployment.

What do you get instead?

Deployment script continues.

Additional info

Proposed solution

Use YII_ENV_TEST as indicator for the 'test environment' and exit the application when an exception occurs.
Add new constant YII_TEST_MODE for running the application in 'test mode' to continue the application after an exception. For example during the use of Codeception/PHPUnit.

This issue was moved by samdark from yiisoft/yii2#16782.

What steps will reproduce the problem?

Define a class with nested models:

class CompletedOrderReviewForm extends Model {
   /** @var OrderReview */
   public $summaryReview;

   /** @var OrderReview */
   public $primaryReview;

   /** @var OrderReview[] */
   public $otherReviews = [];

	public function rules() {
		return [
			[['summaryReview', 'primaryReview', 'secondaryReviews'], 'safe'],
                        // some complex validation here
		];
	}
}

Render inputs through ActiveForm:

<?= $form->field($formModel, 'summaryReview[rate]')
		->textInput([
			'type' => 'number'
		]) ?>

What is the expected result?

The expected label of the input is 'Rate'.

What do you get instead?

The label of this input is 'Summary Review'.

Additional info

Currently there's 3 properties in yii\base\Application that seem to have no function than for debugging:

	/**
	 * @var string the requested route
	 */
	public $requestedRoute;
	/**
	 * @var Action the requested Action. If null, it means the request cannot be resolved into an action.
	 */
	public $requestedAction;
	/**
	 * @var array the parameters supplied to the requested action.
	 */
	public $requestedParams;

The commit message where they were added was Yii debugger WIP. I think it makes sense to remove these.

Instead the debug module should use events to gather the data it needs and they should not be stored as public properties on the application class.

3.0 is compatible with 2.0 extensions
Does the official old 2.0 extension consider removing prefixes like yii2-debug, yii2-queue, yii2-httpclient
Does the new extension official recommend the yii2- prefix?
I am currently designing an application based on yii2 and consider giving up the 2.0 version, but I have a lot of old extensions that use the yii2- prefix.
For 3.0 I can now refactor to remove the yii2- prefix?

Currently runAction is implemented in Module.
However it is only ever called for root modules, which are Applications.

This won't break BC in most applications but since it doesn't functionally add anything I propose doing this in 2.1

now developers can use loadDefaultValues() for ActveRecord, but can`t use it at base Model, think it will be usefull feature to load values that have default value validation rule.

public function loadDefaultValues() {
	foreach ($this->getActiveValidators() as $validator) {
		if ($validator instanceof DefaultValueValidator) {
			$validator->validateAttributes($this, $this->activeAttributes());
		}
	}
}

Hi
i think this feature is need for big project that using internationalization(I18N).
but where is it used?
this is used in interaction between server I18N and client project like javascript.
i prepared a sample example.

Yii messages file in TreeView category

return [
    'Hello' => 'سلام',
    'Good' => 'خوب',
];

in javascript

var obj = new MyTreeViewClass();
obj->languages = '<?=yii::t('TreeView',null)?>';

in above js example i use null parameter for t method, because null means get all message from TreeView category.

also see
how i can get a category message in yii ?

@yccphp commented on Mar 26, 2015, 7:50 AM UTC:

log:

The message file for category 'yii' does not exist: /Applications/MAMP/htdocs/phpcto/trunk/application/admin/vendor/yiisoft/yii2/messages/zh/yii.php

web.php 
    'language' => 'zh_CN',

What reason is this error?

PhpMessageSource 

:72 line
protected function loadMessages($category, $language) 

// Why the truncation
$fallbackLanguage = substr($language, 0, 2);

zh_CN => zh 

message /  
zh 
 This folder is not useful

This issue was moved by samdark from yiisoft/yii2#7883.

\yii\base\Controller accepts configuration data array as constructor param, but \yii\base\Module::createController() nor \yii\base\Module:: createControllerByID() don't. I suggest to add param $config = [] to both of these methods and pass it further to created controller.

See https://github.com/yiisoft/core/commit/c6e0e031d419881d1c02d4894155e94516da1a26
Application::t() is too long than Yii::t().This method is often used. What about App::t()?

The framework code should never use specific behaviour like this:

if (YII_ENV_TEST) {
   throw new ExitException($status);
}

https://github.com/yiisoft/yii-core/blame/aa1c38c3e0533c4def419ecdaf53d6a5f8167514/src/base/Application.php#L678

It is responsibility of unit test to decide whether returned response code is expected or not.

Currently I see no way of extending controller with its actions because the render function at the end returns the HTML content instead of a View object which can be manipulated before render to HTML. Let me just give you an example:
We have a BaseController which renders a gridview with a $dataProvider param. Later I want to extend the BaseController's index action and to add aditional parameters or modify the existing ones so I override the actionIndex method and when I use parent::actionIndex() the return value is string. So there is no way to override it(without some kind of workaround this limitation).
There is a slight inconsistency here because for example the RestController's actions return arrays or object and thus can be easily overridden, There results are later rendered to string which is returned.
IMO the controllers should return View objects(not rendered) which can be modified and then later rendered in runActionFunction for example. What do you think ?

As the manual specifies: Components are the main building blocks of Yii applications.

Many components depend on other components, here is a list for the core components:
yii\web\View has: Yii::$app->getAssetManager()

yii\i18n\Formatter has: Yii::$app->timeZone and Yii::$app->language. Note these are not components.

yii\i18n\I18N has: Yii::$app->language. Not a component.

yii\web\UrlManager has: Yii::$app->get($this->cache, false), depends on a dynamically configured cache component.

yii\web\AssetManager has: Yii::$app->charset). Not a component.

yii\web\Request has: Yii::$app->getSecurity(), Yii::$app->getSession(), Yii::$app->getResponse().

yii\web\Response has: Yii::$app->getRequest(), Yii::$app->getSecurity().

yii\web\Session has: Yii::$app->getRequest()

yii\web\User has: Yii::$app->getRequest(), Yii::$app->getSession(), Yii::$app->getUrlManager(), Yii::$app->getResponse(), Yii::$app->getAuthManager().

As can be seen, especially in the web components, there are a lot of (circular) dependencies).
These circular dependencies could be indicators that some components could use refactoring.

It could be nice to clean this up a bit for 2.1

I have seen all the moves and new repos being created for Yii v3.0 and would like to know more about the discussions that are happening so that I can learn deeper about Yii structure and the motivations for each decision. It will give me conditions to contribute better in the future and will improve my Yii and OOP knowledges.

So, is there any public online places where those things are being planned and any developper would be welcome to "watch" or maybe participate in?

Thank you.

When using relative links (or links w/o http protocol) with Formatter::asUrl() they become broken:
/some/page.html -> <a href="http:///some/page.html">/some/page.html</a>
#anch123 -> <a href="http://#anch123">#anch123</a>
//example.com/page/ -> <a href="http:////example.com/page/">//example.com/page/</a>

Is a good idea to add some checks in method asUrl()? Like this:

if (strpos($url, '://') === false) {
    if (strpos($url, '/') !== 0 && strpos($url, '//') !== 0 && strpos($url, '#') !== 0) {
        $url = 'http://' . $url;
    }
}

Additional info

Your Commit 3e3a978, generates this error,

Thks,

This issue was caused by discussion from this commit: cbe2365

Seems that application will be injected in some places like controllers but other places will need to use old static way using Yii::getApp().

I agree with @rob006 that it should be injected in all places or all places should use statics. But is it possible?

Please join the discussion and tell us what do you think 😄

Exception trace:
() at /Volumes/Data/yii2-demo/vendor/yiisoft/yii-core/config/common.php:30
Composer\Util\ErrorHandler::handle() at /Volumes/Data/yii2-demo/vendor/yiisoft/yii-core/config/common.php:30
require() at /Volumes/Data/yii2-demo/vendor/hiqdev/composer-config-plugin/src/readers/PhpReader.php:27
hiqdev\composer\config\readers\PhpReader->readRaw() at /Volumes/Data/yii2-demo/vendor/hiqdev/composer-config-plugin/src/readers/AbstractReader.php:31
hiqdev\composer\config\readers\AbstractReader->read() at /Volumes/Data/yii2-demo/vendor/hiqdev/composer-config-plugin/src/Builder.php:287
hiqdev\composer\config\Builder->loadFile() at /Volumes/Data/yii2-demo/vendor/hiqdev/composer-config-plugin/src/Builder.php:144
hiqdev\composer\config\Builder->loadConfigs() at /Volumes/Data/yii2-demo/vendor/hiqdev/composer-config-plugin/src/Builder.php:132
hiqdev\composer\config\Builder->buildConfigs() at /Volumes/Data/yii2-demo/vendor/hiqdev/composer-config-plugin/src/Plugin.php:128
hiqdev\composer\config\Plugin->onPostAutoloadDump() at n/a:n/a
call_user_func() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:176
Composer\EventDispatcher\EventDispatcher->doDispatch() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:96
Composer\EventDispatcher\EventDispatcher->dispatchScript() at phar:///usr/local/bin/composer/src/Composer/Autoload/AutoloadGenerator.php:312
Composer\Autoload\AutoloadGenerator->dump() at phar:///usr/local/bin/composer/src/Composer/Installer.php:303
Composer\Installer->run() at phar:///usr/local/bin/composer/src/Composer/Command/UpdateCommand.php:162
Composer\Command\UpdateCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Command/Command.php:241
Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:843
Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:193
Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:254
Composer\Console\Application->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:117
Symfony\Component\Console\Application->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:103
Composer\Console\Application->run() at phar:///usr/local/bin/composer/bin/composer:56
require() at /usr/local/bin/composer:24

update [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--lock] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [--with-dependencies] [--with-all-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [-i|--interactive] [--root-reqs] [--] []...

@Bertagit commented on Mar 12, 2018, 2:14 PM UTC:

When missing a category translation the framework throw an error exception.

If this behavior will be managed by a warning and the i18n class return the source string instead an exception so we can have a report about the missing translation but without compromise the site functions.

This issue was moved by samdark from yiisoft/yii2#15883.

Sometimes need to use only events&behaviors code from Component, not magic __get __set and __contructor($config) from BaseObject.

class Post implements ComponentEventInterface
{
    use ComponentTrait;

    private $title;

    public function __construct($title)
    {
        $this->title = $title;
    }

    public function changeTitle($title)
    {
        $this->title = $title;
        $this->trigger(TitleChangedEvent::NAME, new TitleChangedEvent());
    }
}

https://github.com/yiisoft/core/commit/6d16c1c2d9143f1edde2cc349b2e8b9bd7b87358 +1

Hi, I have a question revising the Yii 3.0 code when I can use $this>app or Yii::getApp(), I see that in yiisoft/app/controller/sitecontroller.php using $this->app and in the Yii::getApp() in view,

I would like to always use $this->app to avoid static calls.

Thanks.

@vercotux commented on Jul 10, 2017, 4:44 AM UTC:

Consider the following scenario:

1. Take any module with a '_form' view containing an ActiveForm.
2. Render module's '_form' outside of module (eg. in main app site/index view). For example: $this->render('@somevendor/somemodule/frontend/views/post/_form', ['model'=>$model]);

The rendered ActiveForm 'action' URL in our module's '_form' will be incorrect no matter what we do:

• If the form uses a relative route (eg. ['post/create']) then the URL will be pointing to the wrong controller (app's instead of module's).
• If the form uses a fixed absolute route (eg. ['//module/post/create']) then the URL will be pointing to the potentially wrong module ID (it could be called something other than "module").
• If we try to dynamically grab the module's ID (eg. by doing ['//'.Module::getInstance()->id.'/post/create']) we will end up with a "Trying to get property of non-object" exception.

The mechanism to access the module externally without knowing its ID in advance seems to be missing and/or is not documented.

This issue was moved by samdark from yiisoft/yii2#14421.

move \yii\web\UrlRule to \yii\route\UrlRule
move \yii\web\GroupUrlRule to \yii\route\GroupUrlRule

yii-web require yii-route
yii-rest require yii-route

Why are some yiisoft repos are prefixed with yii- like yii-web or yii-console and others not, like db and cache?

See also yiisoft/yii-base-web#40 (comment)

It's necessary remove widgets and grid from core.

I think better to create a new repository widgets and move the source

A lot of code in Yii2 uses array_values for suboptimal cases.

What steps will reproduce the problem?

array_values requires:

• The argument to be an array
• Extra memory

In cases where we just want to iterate and ignore the keys, we should do just that. Also removing these unneeded calls will open the way for better support of iterables in a more generic way.

What is the expected result?

I expect things like gridviews or serializers to support anything they can iterate over.

What do you get instead?

They can only iterate over arrays.

Additional info

For 2.1 it might be interesting to look at https://github.com/nikic/iter which implements a lot of iteration primitives that we could use instead.

Steps

• yii\grid\GridView::renderTableBody()
• yii\widgets\ListView::renderItems()
• yii\widgets\Menu::normalizeItems() && yii\widgets\Menu::renderItems()
• yii\log\Logger::getProfiling() && yii\log\Logger::calculateTimings()
• yii\rest\Serializer::serializeDataProvider()

Previously there was a pull request related to middleware support: yiisoft/yii2#15416.
I don't see it in the change log now: https://github.com/yiisoft/yii-core/blob/master/CHANGELOG.md

Did you remove it or just forgot to add to the change log?

And also one more question: where can one find info about 3.0 current status, plans and discussions?

@sanwv commented on Oct 19, 2018, 9:55 AM UTC:

What steps will reproduce the problem?

when component and module has a some id ,e.g.

'bootstrap'=>['my'],
'modules'=>['my'=>xxx:class],
'components'=>['my'=>yyy:clsss]

What is the expected result?

module bootstrap can work

What do you get instead?

 'bootstrap' => [function ($app) {
        $app->getModule('my')->bootstrap($app);
    }],

Additional info

This issue was moved by samdark from yiisoft/yii2#16804.

It seems reasonable when you inherit some base action class and want to further process the result or change behavior of afterRun() depending on the result. But are there any caveats of passing whole result every action run? Or any other methods? Right now inheriting yii\base\Action and duplicating runWithParams() doesn't seem ok.
Some distantly related issue: yiisoft/yii2#2549.

I think Controller::run() should be removed. It's not used anywhere in the framework.

What steps will reproduce the problem?

Try to override run().

What is the expected result?

• Application resolves request
• Application creates controller
• Application calls ->run() on controller
• Controller calls ->runAction() for the specified action.

What do you get instead?

• Application resolves request
• Application creates controller
• Application calls ->runAction() on controller

Additional info

To me it seems this should not be part of the core framework; it provides a way to execute other routes from a controller. Doing that does not feel like a good practice that should be stimulated.
If it is really needed one should use app->runAction instead and re-resolve the whole route instead of this random shortcut.

Why is hiqdev/composer-config-plugin a dev-dependency?

From my understanding it is used to generate configs for applications (-templates), but why is it in the core?