Is there a way to allow each dev on a team to change AWS region for a project that wouldn't be committed? maybe like a

sst.local.json

haha... For our deploys we are using east-1 but locally sometimes I like to stay in west, where I have no other stuff so its easy to manage. I only know of

sst.json

and then

package.json

I could add region to my scripts, but both of those are shared files. Any other ways override?

I would love the ability to define stage/region pairs somewhere

I never even liked specifying it in sst.json, we should just respect normal AWS conventions....which I think we do?

Does that work now? if I set

AWS_REGION

locally does it override

sst.json

? Still not totally ideal though as I would like to have per project control. Maybe we could provide

sst.config.js

that returns the same data as

sst.json

at least then I could check envs? 🤷‍♂️

I'm not sure, @Frank knows a bit better how the bootup process works to figure out all your profile info

well I do stuff like this in my package.json but it seems wack

"deploy:test": "AWS_PROFILE=platform-dev npm run deploy -- --stage test --region eu-west-1 ",
    "deploy:prod": "AWS_PROFILE=platform-prod npm run deploy -- --stage prod --region us-east-1 ",

wack because: 1. shit in package.json scripts is unreadable 2.

--stage

is a CLI flag but profile is a env var (Serverless lets you specify both as CLI flags) 3. if i want to run other commands (e.g.

remove

) on these stages I have to set the profile manually and the scripts don't help

we should support profile as a cli flag just like aws-cli

yeah thats no good. plus

package.json

is shared so as soon as another dev on the team wants to test in east-2 they have to muck with it and then remember to revert before check in.

one idea: move region from sst.json to .sst/stage

oh interesting,

.sst/

is kinda where I planned to put all local specific config

and ideally a shared config for shared environments that has profile/stage/region triplets

.sst

folder is possible but also a bit odd. Just because it has always seemed to be a "managed" folder, gitignored and controlled by sst. So as a first time dev/clone process if i wanna dev on a different region then whats in

sst.json

I would need to create a

.sst

folder and add something in it before running start or deploy

yeah, a distinction between "my local private default stage" and "shared stages" - one could be in .sst and one could be in say sst.json

yeah

sst.config.t/js

seems like a pretty easy win

THAT"s the solution

or just know what keys/values are allowed

right, you could have both though. code always wins over json if they both exist.

yep exactly, I love that pattern in vite, that's what we should go to

import { defineConfig } from '@serverless-stack/cli'

export default defineConfig({
  name: 'my-project',
  region: 'us-east-1',
  main: 'stacks/index.js',
})

ish

perfect

So with this one could just implement a simple

dotenv

read whatever they wanna swap

@Ross Gerbasi but how would you switch between environments exactly? like say I want to deploy to my personal env, or to test, or to production

👀

import 'dotenv/config'
import { defineConfig } from '@serverless-stack/cli'

const config = {
  name: 'my-project',
  region: 'us-east-1',
  profile: 'my-main-aws-profile',
  main: 'stacks/index.js',
}
export default defineConfig(
  process.env.ENVIRONMENT === 'test'
    ? Object.assign(config, {
        region: 'us-west-1',
        profile: 'my-second-aws-profile',
      })
    : config,
)

Then something like

cross-env ENVIRONMENT=TEST && npx sst deploy

CDK has a different approach btw, you're supposed to instantiate different apps for different environments, but that never made much sense to me

yeah that sounds like silliness haha. Maybe i am missing something but i thought the whole point was one app with easy deploy.