Add the ability to export values from `supabase start` to an `.env.local` file
Feature request
Is your feature request related to a problem? Please describe.
So I'm working on a project where I'm using codespaces for an ephemeral development environment, but this could equally apply to gitpod as well.
One of the issues I'm coming up against is that when I make a new codespace/container, I need to manually create a new .env.local file with the anon and service_role keys. This is not major, but it would be super nice to be able to start work without this step.
Describe the solution you'd like
I was thinking there could be a option flag on supabase start like supabase start --value-file and perhaps some config in supabase/config.toml like
[value_file]
path = "./.env.local"
file_type = "env"
anon_key = "NEXT_PUBLIC_SUPABASE_ANON_KEY"
service_role_key = "SUPABASE_SERVICE_ROLE_KEY"
api_url = "NEXT_PUBLIC_SUPABASE_URL"
Which would create the correct file based on the path, file_type and mappings. In this case a .env.local file at the projects root.
Describe alternatives you've considered
Another solution could be creating environment variables directly however that would not be as flexible and would still need the mappings.
Another solution could be to provide the values to use like
supabase start --anon-key="sknsdjkbnhn" --service-role-key="cndjkskcnsdjkn"
Another benefit could be to compile your frontend in parallel with the docker image download / seed
I have attempted to have go at this myself, but only supporting env files here #452
I think this would be really useful for CI purposes as well. For example, it would be nice to have the proper environment variables automatically filled in so that Cypress tests can be run in CI.
Just wound up on this because it looks like the default keys are all hardcoded and not generated. Would be extremely nice to have something better!
Exporting env vars is now possible with the status command:
supabase status -o env
More examples are available under -h flag.
@ryanalta do you mind creating a separate issue for making the hardcoded values dynamic/configurable?
@sweatybridge can do!