You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently some of the config set in plenti.json can be referenced in the magic env prop available at the top-level /layouts/global/html.svelte of your project:
env.baseurl
env.local
env.entrypointHTML
env.entrypointJS
env.cms.repo
env.cms.redirectUrl
env.cms.appId
env.cms.branch
I wonder if it makes sense to reserve env for custom key/values and instead pull defined settings out of a new variable called config:
config.baseurl
config.local
config.entrypointHTML
config.entrypointJS
config.cms.repo
config.cms.redirectUrl
config.cms.appId
config.cms.branch
config.env.myCustomKey <-- User defined under env key in plenti.json
config.env.myCustomKey2 <-- Same
Most projects allow for a .env file, but since we allow individual builds per environment (e.g. local / dev / stg / prod / etc.. per #183) using plenti.json config files, I think it makes the most sense to require that we define them there.
To avoid introducing a breaking change we could keep env and using a subcategory of custom or something instead. Would like to emphasize the best naming over backwards compatibility though.
The text was updated successfully, but these errors were encountered:
Currently some of the config set in
plenti.json
can be referenced in the magicenv
prop available at the top-level/layouts/global/html.svelte
of your project:env.baseurl
env.local
env.entrypointHTML
env.entrypointJS
env.cms.repo
env.cms.redirectUrl
env.cms.appId
env.cms.branch
I wonder if it makes sense to reserve
env
for custom key/values and instead pull defined settings out of a new variable calledconfig
:config.baseurl
config.local
config.entrypointHTML
config.entrypointJS
config.cms.repo
config.cms.redirectUrl
config.cms.appId
config.cms.branch
config.env.myCustomKey
<-- User defined underenv
key inplenti.json
config.env.myCustomKey2
<-- SameMost projects allow for a
.env
file, but since we allow individual builds per environment (e.g. local / dev / stg / prod / etc.. per #183) usingplenti.json
config files, I think it makes the most sense to require that we define them there.To avoid introducing a breaking change we could keep
env
and using a subcategory ofcustom
or something instead. Would like to emphasize the best naming over backwards compatibility though.The text was updated successfully, but these errors were encountered: