Move dotenv to "require" #132
Conversation
This PR was merged into the 3.4 branch. Discussion ---------- Move dotenv to "require" This doesn't hurt anything and should ease using .env files without issues. Commits ------- e9c7e08 Move dotenv to "require"
|
@nicolas-grekas @weaverryan sorry for re-opening this topic but I have just found an issue with installing 3.4 LTS. if you use Basically, just like it is written in https://symfony.com/download, it will pull 3.4 website skeleton where dotenv still remains in require-dev. |
|
Furthermore if you go to https://packagist.org/packages/symfony/website-skeleton#v3.4.0 you can still see that dotenv is in require-dev section. |
|
@sargath you don't want to download v3.4.0 of the website-skeleton, you need the latest version of it, which does not have Dotenv in require-dev: https://packagist.org/packages/symfony/website-skeleton#v3.4.21.2 |
|
@Pierstoval yes, so imho website docs should point to 3.4.21.2 instead --version=3.4 |
|
@Pierstoval Check this out also. sargath ~/Projects $ symfony new my_project --full --version=3.4
* Creating a new Symfony 3.4 project with Composer
(running /home/sargath/.php-tools/bin/composer create-project symfony/website-skeleton my_project 3.4)
* Setting up the project under Git version control
(running git init my_project)
[OK] Your project is now ready in /home/sargath/Projects/my_project
sargath ~/Projects $ cat my_project/composer.json
{
"type": "project",
"license": "proprietary",
"require": {
"php": "^7.0.8",
"ext-iconv": "*",
"sensio/framework-extra-bundle": "^5.1",
"symfony/asset": "^3.4",
"symfony/browser-kit": "^3.4",
"symfony/console": "^3.4",
"symfony/css-selector": "^3.4",
"symfony/debug-pack": "*",
"symfony/expression-language": "^3.4",
"symfony/flex": "^1.0",
"symfony/framework-bundle": "^3.4",
"symfony/form": "^3.4",
"symfony/lts": "^3",
"symfony/orm-pack": "*",
"symfony/monolog-bundle": "^3.1",
"symfony/process": "^3.4",
"symfony/security-bundle": "^3.4",
"symfony/serializer-pack": "*",
"symfony/validator": "^3.4",
"symfony/swiftmailer-bundle": "^3.1",
"symfony/web-link": "^3.4",
"symfony/webpack-encore-pack": "*",
"symfony/yaml": "^3.4"
},
"require-dev": {
"symfony/dotenv": "^3.4",
"symfony/maker-bundle": "^1.0",
"symfony/phpunit-bridge": "^3.4",
"symfony/profiler-pack": "*"
},
"config": {
"preferred-install": {
"*": "dist"
},
"sort-packages": true
},
"autoload": {
"psr-4": {
"App\\": "src/"
}
},
"autoload-dev": {
"psr-4": {
"App\\Tests\\": "tests/"
}
},
"replace": {
"symfony/polyfill-iconv": "*",
"symfony/polyfill-php70": "*",
"symfony/polyfill-php56": "*"
},
"scripts": {
"auto-scripts": {
"cache:clear": "symfony-cmd",
"assets:install %PUBLIC_DIR%": "symfony-cmd"
},
"post-install-cmd": [
"@auto-scripts"
],
"post-update-cmd": [
"@auto-scripts"
]
},
"conflict": {
"symfony/symfony": "*"
},
"extra": {
"symfony": {
"id": "",
"allow-contrib": false
}
}
} |
|
I think this is an issue with the Symfony CLI, not the skeleton. Could you report this same issue in symfonycorp/symfony-cli-issues? |
|
@Pierstoval sure no problem I can report this, but FYI same happens with pure composer |
|
This works: |
|
Yeah sure, @nicolas-grekas after specifying versions it works, I know, but just wanted point this out since someone, that will just copy/paste link from website will get this version of composer.json with dotenv in -dev section and it may blow up on prod env. |
|
If you spotted places where things should be updated, please submit a PR to improve it! |
|
@nicolas-grekas ok sorry :) I haven't been sure if this is an issue |
|
... but anyway symfony website isn't probably open for creating PRs, am I right? :) Which project would you propose where I can submit an issue or PR? |
|
@sargath fixed thanks, soon released if not already. |
…s logic (cristi-contiu) This PR was submitted for the 4.1 branch but it was merged into the 4.4 branch instead. Discussion ---------- [Deployment] Update deployment docs with new .env files logic The [changes from last year regarding how the ``.env`` files are loaded](https://symfony.com/doc/current/configuration/dot-env-changes.html) can affect production deployments. Vendors like [Heroku](https://devcenter.heroku.com/articles/deploying-symfony4#environment-variables) give recommendations based on documentation that no longer applies: "It is recommended that you do not use the symfony/dotenv package in production". The ``symfony/dotenv`` has been moved from ``require-dev`` to ``require``, so the note I removed in this PR no longer applies: symfony/skeleton#122 , symfony/website-skeleton#132 and symfony/demo@7ead1e4 . Loading ``.env`` files in production will work without any changes in composer.json. Putting ``symfony/dotenv`` in ``require-dev`` (or not moving it to ``require`` during an upgrade from older versions of Symfony & recipes) can potentially break your app: if the DotEnv class is missing, the [`config/bootstrap.php` file inside the FrameworkBundle's recipe will throw a RuntimeException](https://github.com/symfony/recipes/blob/master/symfony/framework-bundle/3.3/config/bootstrap.php#L14) . Also see symfony/recipes#501 The note now contains the right way to handle these files in production, by using ``$ composer dump-env prod`` in case you do not want the ``.env`` files to be processed on every request, also suggesting the ``--empty`` flag if you want to rely exclusively on "real" environment variables . Commits ------- b905b57 Update deployment docs with new .env loading
This doesn't hurt anything and should ease using .env files without issues.