This adds an --envFile, -e flag to stencil init and stencil start commands.
For stencil init, providing the flag will save Stencil configuration to the provided env filename (e.g. .env) except for the custom layouts.
For stencil start, providing the flag will read Stencil configuration from the provided env filename instead of from the JSON files except for the custom layouts.
Marking this as draft for now to have your thoughts on this first before continuing on other commands / making tests succeed. Open to changing approach, or also suggestions instead of merging this PR.
Why?
In our agency, we are planning on eventually eliminating plaintext secrets from the local machines of the developers. We are using 1Password to store the secrets and in local development, the secrets are stored as "secret references" instead of having it as plaintext in .env files.
For Stencil theme development, the op run command cannot be used because Stencil CLI stores the secret in JSON files instead of env files.
We have considered having template config/secrets JSON files and using op inject to generate the JSON files used by the CLI and delete those after the Stencil command is ran. However, there are worries about things going wrong in the script that will leave the secrets.stencil.json undeleted.
We have a PoC that has simpler approach that just overrides the StencilConfigManager to read from system env vars directly, but maintaining a fork is not preferred. So this PR is opened with a more inclusive approach that is opt-in by providing a flag and allows not using 1Password CLI.
What?
This adds an
--envFile, -eflag tostencil initandstencil startcommands.For
stencil init, providing the flag will save Stencil configuration to the provided env filename (e.g..env) except for the custom layouts.For
stencil start, providing the flag will read Stencil configuration from the provided env filename instead of from the JSON files except for the custom layouts.Marking this as draft for now to have your thoughts on this first before continuing on other commands / making tests succeed. Open to changing approach, or also suggestions instead of merging this PR.
Why?
In our agency, we are planning on eventually eliminating plaintext secrets from the local machines of the developers. We are using 1Password to store the secrets and in local development, the secrets are stored as "secret references" instead of having it as plaintext in
.envfiles.For Stencil theme development, the
op runcommand cannot be used because Stencil CLI stores the secret in JSON files instead of env files.We have considered having template config/secrets JSON files and using
op injectto generate the JSON files used by the CLI and delete those after the Stencil command is ran. However, there are worries about things going wrong in the script that will leave thesecrets.stencil.jsonundeleted.We have a PoC that has simpler approach that just overrides the
StencilConfigManagerto read from system env vars directly, but maintaining a fork is not preferred. So this PR is opened with a more inclusive approach that is opt-in by providing a flag and allows not using 1Password CLI.Tickets / Documentation
https://developer.1password.com/docs/cli/use-cases#secrets https://developer.1password.com/docs/cli/secrets-environment-variables/ https://developer.1password.com/docs/cli/secrets-config-files/
cc @bigcommerce/storefront-team