curious if there’s a canonical way to handle shared dev envs with ESC. We have a bunch of config that ideally would be centralized in ESC, but there are some developer specific configurations (e.g the database name they’re connecting to). Doppler has a neat solution for this with branching & personal configs: https://docs.doppler.com/docs/branch-configs#personal-configs

Hey! This is a core use case for ESC and we use this pretty regularly in our own processes. [Imports](https://www.pulumi.com/docs/esc/environments/imports/) are the way to achieve this. Concretely, we have a

dev-stacks

environment that has all our baseline configuration. Individual devs import the

shared/dev-stacks

environment into their own environment (e.g.

dev/komal

), and overwrite or add keys that are specific to their workflows/environments (like db name or specific api keys if relevant) and then use those for our IaC stacks or in our CLI processes. Does that solve what you're looking for?

that seems like it would def solve the dev specific variable issue, thank you. We’d have a slight challenge moving to this model. for context, we have a big monorepo, and then in each subpackage, today, we have the

dev

command in package.json set to something like

esc run shared-dev-env — ts-node …

. 90% of the config is in a .gitignore’d .yaml file (so devs can change their config as needed), which is what i’m trying to move into our ESC env & prompted this question. So if we move to developer-specific environments (

dev/jm

instead of

dev/shared-env

), we obviously can’t hardcode the env name in package.json anymore. so in theory a dev could run

esc run dev/jm — npm run dev

, but we have a big monorepo, so when you run

npm run dev

at the root, it runs the

dev

command in all subpackages, so you’d want a different env per subpackage (ie you wouldn’t want to run

esc run dev/jm — npm run dev

at the root). i can hack my way around this - in the subpackage’s package.json, we can make

dev

run

esc run $(cat ./current_env) -- ts-node ...

and just gitignore

current_env

, so devs can just point that file at their personal env. but being able to associate esc envs with a specific directory locally would be a very useful feature. doppler does this, ie you run

doppler configure

and then it sets that directory to a specific env, so when you run

doppler run -- mycommand

it just runs whatever env is configured for the cwd

I think that's definitely a feature we're open to supporting and would love it if you could open an issue - in the meanwhile I wonder if integrating with direnv might suffice as a workaround?

you could use direnv to set a environment variable with the esc environment on a per-directory basis, and then interpolate that in your package.json command:

# .envrc
export ESC_ENV="dev/jm"

# package.json
"scripts": {
  "dev": "esc run $ESC_ENV -- ts-node ..."
}