-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Update Multiple_kernels.rst #10481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Multiple_kernels.rst #10481
Conversation
I would like to propose to change the following: After a change in the classmap in composer.json, I would recommend using 'composer dumpautoload', instead of doing a 'composer install'. The main reasoning behind this is that after a 'composer install' the parameters.yml file is regenerated, and your own parameters stored there are gone (learned this the hard way :) )
That's weird, though. If you're using incenteev-parameters, only new parameters are added, never updated. Unless using env vars to set the parameters. |
Hello @ogizanagi . I honestly have no idea why this happened, all I can tell you is I have a standard 3.4.17 install of Symfony, and I'm checking out the docs to get up to speed with the framework. I did however check something : I am using the incenteev-parameters (I think), and am NOT using env vars (not to my knowledge at least :) ). But perhaps this is an issue to be filed somewhere else? Since this is the docs repo, I mean? Tnx, |
configuration/multiple_kernels.rst
Outdated
@@ -119,7 +119,7 @@ to your ``composer.json`` autoload section: | |||
} | |||
} | |||
|
|||
Then, run ``composer install`` to dump your new autoload config. | |||
Then, run ``composer dumpautoload`` to dump your new autoload config. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we should use the official Composer command name that is dump-autoload
, it's also easier to read.
Source: https://getcomposer.org/doc/03-cli.md#dump-autoload-dumpautoload-
Then, run ``composer dumpautoload`` to dump your new autoload config. | |
Then, run ``composer dump-autoload`` to dump your new autoload config. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh : you learn something new everyday :) . I've been so used to using dumpautoload, I've never considered it was an alias.
Can only agree to this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please update :)
Ouch, this one slipped under the radar, sorry :) |
Thank you @Alienpruts. |
This PR was squashed before being merged into the 3.4 branch (closes #10481). Discussion ---------- Update Multiple_kernels.rst I would like to propose to change the following: After a change in the classmap in composer.json, I would recommend using 'composer dumpautoload', instead of doing a 'composer install'. The main reasoning behind this is that after a 'composer install' the parameters.yml file is regenerated, and your own parameters stored there are gone (learned this the hard way :) ) <!-- If your pull request fixes a BUG, use the oldest maintained branch that contains the bug (see https://symfony.com/roadmap for the list of maintained branches). If your pull request documents a NEW FEATURE, use the same Symfony branch where the feature was introduced (and `master` for features of unreleased versions). --> Commits ------- 5cd7a3a Update Multiple_kernels.rst
I would like to propose to change the following:
After a change in the classmap in composer.json, I would recommend using 'composer dumpautoload', instead of doing a 'composer install'.
The main reasoning behind this is that after a 'composer install' the parameters.yml file is regenerated, and your own parameters stored there are gone (learned this the hard way :) )