Laravel 5.8 update breaks third-party composer libraries

[nomad-software]

• Laravel Version: 5.8.5
• PHP Version: 7.2.12
• Database Driver & Version: n/a

Description:

When upgrading our applications to use Laravel v5.8 there is a major breaking change in the way environment variables are being handled which renders useless the majority of third-party composer libraries that use PHP's getenv function.

This change is documented here: https://laravel.com/docs/5.8/upgrade which is great, and which we are using to upgrade our systems. Unfortunately this guide does not cover the actual change that was made in the underlying way the Dotenv library is being used. For whatever reason the adapter that was being used to populate the environment that getenv uses is no longer being loaded. This is a huge breaking change that effects an entire ecosystem of third-party libraries when being used with Laravel.

There was an issue raised here which was recently closed: #27913 In that issue, the response was to use the Laravel env helper instead of PHP's getenv function. This is good advice for Laravel applications where you are in control of all code but for third-party composer libraries this is not possible. There are literally thousands of libraries out there that have no idea they are being used with Laravel and use getenv internally.

What this ultimately means is that it's impossible for us to upgrade any of our applications to Laravel 5.8 while this is broken.

Steps To Reproduce:

Use any code (including any third-party composer library) that uses getenv to load an environment variable from the .env file. It always returns false.

[driesvints]

getenv & putenv work just fine for any environment variable outside Laravel's .env environment. I've just tested this on a fresh 5.8 app. If you have an integration which relies on integrating with Laravel you should use a custom config file and use the env helper.

[driesvints]

Use any code (including any third-party composer library) that uses getenv to load an environment variable from the .env file. It always returns false.

This indeed won't work anymore but that's documented in the upgrade guide. In this situation you should replace getenv with the env helper.

[nomad-software]

getenv & putenv work just fine for any environment variable outside Laravel's .env environment.

Yes, I understand that but we are using Laravel here.

I've just tested this on a fresh 5.8 app. If you have an integration which relies on integrating with Laravel you should use a custom config file and use the env helper.

This would make sense if we are the ones who were responsible for the code. This code is in a third-party library that uses getenv throughout. We have no access to the code other than changing the vendor'ed dependency loaded through composer.

This indeed won't work anymore but that's documented in the upgrade guide. In this situation you should replace getenv with the env helper.

How can I do this if it's a third-party library? Also you are implying the library uses Laravel and has access to the helper. We are using an AWS library which is framework agnostic and will never be able to use the Laravel env helper. This also applies to hundreds, if not, thousands of framework agnostic PHP libraries that use getenv.

Do you understand that the Laravel env helper function is not available outside of the Laravel framework? Developers rely on the getenv function instead when writing a composer library that requires ENV variables.

Why has this been closed? This is a huge breaking change that affects lots of PHP libraries which essentially can't be used with Laravel now.

[driesvints]

You should ask the maintainer to update their library to support 5.8. Which library are we talking about exactly?

Can you provide a practical code example which demonstrate how this breaks your app? Please provide third party libraries in the exact version you're using them.

[nomad-software]

Amazon AWS SDK v3.90.4

I can't understand why there has been no deprecation notices regarding this or notices about such a huge change in functionality on a minor revision. This is disappointing coming from you guys.

[nomad-software]

Another related issue: #27828

[driesvints]

Please link to the library in question.

[driesvints]

I can't understand why there has been no deprecation notices regarding this or notices about such a huge change in functionality on a minor revision. This is disappointing coming from you guys.

Please read our upgrade guide before upgrading.

[nomad-software]

Please link to the library in question.

Are you being serious? https://github.com/aws/aws-sdk-php

Here's another we're having the same problem with:
https://github.com/braintree/braintree_php

Please read our upgrade guide before upgrading.

We were following it to upgrade our services. Nowhere does it say that the Laravel .env file is no longer populating the getenv PHP function and that any third-party libraries that rely on it will fail.

Maybe I can't see it, so can you point that part out please?

[nomad-software]

Here's a few more libraries we've identified as affected:

https://github.com/FriendsOfPHP/PHP-CS-Fixer
https://github.com/googleapis/google-api-php-client-services
https://github.com/vyuldashev/laravel-queue-rabbitmq

[driesvints]

Are you being serious? https://github.com/aws/aws-sdk-php

Yes, I was. I wanted to make sure we were talking about the same one. This library doesn't integrate with Laravel. There's a separate one which does but it's updated to be used with 5.8 and makes use of the env helper in its config file: https://github.com/aws/aws-sdk-php-laravel

Here's another we're having the same problem with: https://github.com/braintree/braintree_php

This library doesn't directly integrates with Laravel either.

Maybe I can't see it, so can you point that part out please?

The docs here: https://laravel.com/docs/5.8/upgrade#environment-variable-parsing link to https://github.com/vlucas/phpdotenv/blob/master/UPGRADING.md where at the bottom it details how we implemented the library according to their upgrade guide in a way not to call functions that aren't tread-safe (like getenv). But I can agree with you that this isn't super obvious. I'll send in a PR to the docs to make this more explicit.

[driesvints]

@nomad-software I really think you're missing the point of what's being discussed here. If you are using the .env file you should always use the env helper and not the getenv function. If you set env variables in any other way (CLI, php config) you can use the getenv function.

[nomad-software]

So we are only allowed to use libraries officially supported by Laravel now? You do realise that packagist contains are little more than that right?

I really think you're missing the point of what's being discussed here.

No you are missing the point. You are breaking developer's environments for no good reason (on a minor release I may add) and have not informed anyone of such a big change.

Why would you introduce a nice elegant way of handling environment variables (the .env file) that developers have been using for years then all of a sudden cripple its use and now advocate defining env vars in multiple different places? This is a huge step backward for no advantage. There is litterally no upside here. You've even broken your own server: #27828