Is .env the recommended way to add “custom context...
# sst
m
Is .env the recommended way to add “custom context” in sst? https://docs.aws.amazon.com/cdk/latest/guide/context.html
f
Hey @Mike McCall!
.env.local
gets handy for storing secrets. Definitely not the best practice, but most folks are familiar with it.
For non-secret configs, I’d try to use
cdk.context.json
,
.env
, or even a config file should all work.
m
Awesome thank you!
f
I haven’t used
cdk.context.json
extensively. But I’d say maybe give it a try first. The values are typed, unlike
.env
everything is a string.
Plus, switching from context to .env later seems pretty straight forward.
m
I used it in a cdk project, but not with an sst project yet
f
I see.. definitely lemme know if u find pros/cons with context/.env.. something worth adding to our docs 😁
m
for sure
I thinks it's worth documenting how to use context in sst. Using it for runtime config is pretty nice and the benefits outlined in the aws doc are clear. Basically anything you'd like version controlled would go into context. cdk.json is hidden in sst so I wonder how feature flags are handled as outlined here? https://docs.aws.amazon.com/cdk/latest/guide/featureflags.html. Test don't load context, you can configure the
<http://cdk.App|cdk.App>
with context, but
<http://sst.App|sst.App>
doesn't accept context. One way to get around this is to load the json in an env variable
CDK_CONTEXT_JSON=$(cat cdk.context.json) npm run test
f
Let me take a better look at this and play around with it.
For your last project, were you storing ur config inside
cdk.json
or
cdk.context.json
?
m
I have one using the “context” key in cdk.json at work. Personal project, went with cdk.context.json. makes it easier as a separate file for test use case
Might be cool to have a “context” key in sst.json.. you do some magic behind the scenes. 😉
f
Yup. Let me go through the context docs in more details.