Support dotenv files #244
Support dotenv files #244
Conversation
|
MiniOxygen just implemented |
| SHOPIFY_STOREFRONT_API_PUBLIC_TOKEN="3b580e70970c4528da70c98e097c2fa0" | ||
| SHOPIFY_STORE_DOMAIN="hydrogen-preview" |
There was a problem hiding this comment.
We have these variables already in the Hydrogen channel in admin. Are these variables automatically created for every Hydrogen channel? If that's true then we should keep the same name here. Otherwise we can simplify it.
There was a problem hiding this comment.
Confirming that these are set up in the admin experience, so it's good that we match them here.
There was a problem hiding this comment.
But we shouldn't be versioning .env - it should be gitignored. We will need to update our README.md to include the preview credentials, or perhaps a .env.example which is versioned and which does include preview credentials, so it's as easy as mv .env.example .env.
There was a problem hiding this comment.
The .env is actually gitignored, I just force-committed it to have it working by default. It won't be committed after devs change its value so I think there shouldn't be any risk, right?
Otherwise, let me know if we still proceed with the .env.example and I'll change it in another PR 👍
(Plus, we need it for local development, so perhaps if we want .env.example we should rename it in the template creation script)
| clientOptions.storeDomain = clientOptions.storeDomain.replace( | ||
| '.myshopify.com', | ||
| '', | ||
| ); |
There was a problem hiding this comment.
Adding this because the SHOPIFY_STORE_DOMAIN variable we have in Hydrogen channel includes .myshopify.com and I'm not sure if this variable is created automatically. If it's automatic, perhaps we should move this code to the h-ui utilities to make it more robust.
cc @frehner
There was a problem hiding this comment.
Probably not the place for this discush, but I do find it odd that our clientOptions doesn't accept a FQDN for the storeDomain argument. While most arguments will be *.myshopify.com domains, it's totally possible to use a custom domain as well - it's just up to the dev.
|
Next version of MiniOxygen ( |
| publicStorefrontToken: env.SHOPIFY_STOREFRONT_API_PUBLIC_TOKEN, | ||
| storeDomain: env.SHOPIFY_STORE_DOMAIN, |
Closes #195
Read from
.envfiles and provide these variables in MiniOxygen'sfetchhandler.We might move this logic to MiniOxygen eventually.Notes:
envobject passed to MiniOxygen, not fromprocess.env..envcontent does not override existing variables inprocess.env.Questions:
.env.development,.env.local, etc? It might be useful in combination with the "env pull" feature we want to implement.--env-pathflag to specify the location of the.envfile? -- There's already--pathfor the root project and we assume.envis there.process.envby prefix? Right now we pass all the process variables to MiniOxygen. I think it doesn't really matter since this is only for local development, and prefixes would start making things confusing again.cc @maxshirshin should we add this functionality directly to MiniOxygen? Or you think it's better in Hydrogen CLI?