Skip to content

Conversation

@innocenzi
Copy link
Member

@innocenzi innocenzi commented Dec 29, 2025

Because injecting Environment is more discoverable and a better DX than injecting AppConfig.

public function __construct(
    private readonly Environment $environment,
) {}

EDIT: so actually, as specified in my comment below, I completely dissociated AppConfig from Environment:

  • The booting process uses Environment::fromEnv indirectly through AppConfig's constructor when resolved from the container
  • Specifying the environment property of the AppConfig in userland will not behave as expected due to that
  • It makes sense that Environment is its own source of truth in the container, it's even easier to spoof in tests

@innocenzi
Copy link
Member Author

innocenzi commented Dec 29, 2025

Actually, I think there is an opportunity to refactor the environment outside of AppConfig. The kernel booting process uses the ENVIRONMENT variable itself indirectly anyway, because AppConfig gets resolved every time with null values, and its environment property gets initialized with ::fromEnv, so even if users set a custom environment value in their config, that wouldn't work.

@innocenzi innocenzi force-pushed the feat/environment-initializer branch from 4ad4f55 to e741d32 Compare December 29, 2025 19:17
@innocenzi innocenzi changed the title feat(core): add Environment initializer feat(core): make Environment its own source of truth Dec 29, 2025
@innocenzi innocenzi changed the title feat(core): make Environment its own source of truth feat(core)!: make Environment its own source of truth Dec 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants