Does the AppEnvironment case value 'prod' bother anyone?

[JeremyM1985]

Is 'prod' a more common convention in a code base over 'production'?

case Production = 'prod';

If 'prod' is more of a common convention why is the case name Production?

And if in your env you set APP_ENV=production the AppEnvironment detect method will return 'local'.

    public static function detect(EnvironmentInterface $environment): self
    {
        $value = $environment->get('APP_ENV');

        return \is_string($value)
            ? (self::tryFrom($value) ?? self::Local)
            : self::Local;
    }

The case name is Production, the method is isProduction() but the value is short hand prod..

I know it's just personal opinion but it just bothers me, lol.

[butschster]

Good point! The inconsistency between the case name and the actual value can be confusing. Ideally, the enum could support more flexible mappings, so that both production and prod (and similar shorthand variations) could be valid inputs for the production environment.

One way to improve this could be by allowing multiple aliases for each environment. For example, prod, production, and maybe even prd could all map to AppEnvironment::Production. This would provide more flexibility and consistency in the environment setup.

If you have some time, it would be awesome if you could help contribute to improving this injector by adding alias support or proposing other improvements that make it more intuitive for developers.

Thanks for raising this!

Here’s an example of how the enum could be improved to handle multiple aliases for environment names:

<?php

declare(strict_types=1);

namespace Spiral\Boot\Environment;

use Spiral\Boot\EnvironmentInterface;
use Spiral\Boot\Injector\ProvideFrom;
use Spiral\Boot\Injector\InjectableEnumInterface;

#[ProvideFrom(method: 'detect')]
enum AppEnvironment: string implements InjectableEnumInterface
{
    case Production = 'prod';
    case Stage = 'stage';
    case Testing = 'testing';
    case Local = 'local';

    private const ALIASES = [
        'prod' => self::Production,
        'production' => self::Production,
        'prd' => self::Production,
        'stage' => self::Stage,
        'stg' => self::Stage,
        'testing' => self::Testing,
        'test' => self::Testing,
        'local' => self::Local,
        'dev' => self::Local,
    ];

    public function isProduction(): bool
    {
        return $this === self::Production;
    }

    public function isTesting(): bool
    {
        return $this === self::Testing;
    }

    public function isLocal(): bool
    {
        return $this === self::Local;
    }

    public function isStage(): bool
    {
        return $this === self::Stage;
    }

    public static function detect(EnvironmentInterface $environment): self
    {
        $value = $environment->get('APP_ENV');
        
        if (\is_string($value) && isset(self::ALIASES[$value])) {
            return self::ALIASES[$value];
        }

        return self::Local;
    }
}

[JeremyM1985]

I think in an ideal scenario where there are no backward compatibility issues, this should really be a don't ask, tell solution.

An enum is a finite set of constants. If the supplied value does not exist, it should throw a LogicException. Currently, if a user supplies a custom APP_ENV value, it defaults to Local, which is unexpected.

Since AppEnvironment is an enum, supplied values should explicitly use one of the enum values. I don't see the need for a user to choose between prd, prod, and production; they are all the same thing. It would greatly simplify everything if only a valid enum value could be used.

I would almost suggest to change prod to production and implement a correction mechanism that maps prod to production, and later update it permanently in a major release that may already include other significant breaking changes. Allowing aliases for an enum somehow goes against the concept of enums.

I'm not sure of the impact of that suggestion is, because to be honest im not deeply familiar with your code base yet, i am just in the midst of cheking it out because i might switch from my projects from Laravel to Spiral.

[merlindiavova]

When I first started this caught me off guard twice, first time in production and second in testing
I have since updated my setups to default to production. The name case Production with value prod is unintuitive.

The cleanest way I think to remedy this, update prod to production and map/reword prod to production in the detect method, emitting a deprecation notice whenever prod is used.

[roxblnfk]

See #1170