AdonisJS 6 @adonisjs/env precedence when shell variables already exist

When a shell variable shares a name with a key defined in an @adonisjs/env schema, the Node.js dotenv loader that AdonisJS 6 relies on (by default) leaves the existing process.env entry intact. This means an exported shell variable with a matching name shadows the .env value before Env.fromSchema(schema) runs validation, so the schema validates against the shell value rather than the committed .env entry.

Confirmed behavior:

• The dotenv loader does not overwrite keys that already exist in process.env; an exported shell variable with a matching name takes precedence.
• @adonisjs/env validates the current process.env state after loading; it does not compare loaded values against the .env file, so shadowing goes undetected by validation.
• AdonisJS 6 provides no Ace command or runtime configuration flag to fail or warn when a process variable shadows a schema‑defined key.

Practical steps for this case:

1. Export a schema variable (e.g., export APP_PORT=9999) and start the AdonisJS server; check the logged port to confirm it uses the exported value.
2. Run a small Node script that imports the schema, invokes Env.fromSchema(), and logs the validated keys. Execute with and without the shell export to observe the difference.
3. After validation, run a snapshot script that writes the schema‑derived key/value pairs to a committed file (e.g., env.snapshot.json) for CI reproducibility.

To enforce a repeatable environment, avoid exporting variables that appear in the schema, or use a bootstrap script that unsets relevant process.env keys before loading .env. If your project commonly exports shell variables that match schema keys, let me know; I can suggest a guard script tailored to your setup.