Environment is not always ideal for keeping secrets. For code that gets deployed on servers or in containers - obviously. But this tool will running on the users personal device in almost all cases. Env vars are much more exposed to 3rd parties and can be read by anything executed from your shell or its forks. That includes random postinstall scripts in that 10GB node_modules folder.
There are workarounds, like aliasing the q command to export ... && q, but supporting inline config and making env usage explicit is still an improvement. Inline config would be a better default, but for now I just wanted to add flexibility without breaking backwards compatibility.
What?
Why?
Environment is not always ideal for keeping secrets. For code that gets deployed on servers or in containers - obviously. But this tool will running on the users personal device in almost all cases. Env vars are much more exposed to 3rd parties and can be read by anything executed from your shell or its forks. That includes random postinstall scripts in that 10GB
node_modulesfolder.There are workarounds, like aliasing the
qcommand toexport ... && q, but supporting inline config and making env usage explicit is still an improvement. Inline config would be a better default, but for now I just wanted to add flexibility without breaking backwards compatibility.