Practically, put the values in build profiles rather than in a file, because a file that works is a file that is either committed or absent, and both are bad.
The shape that works:
A profile per target - development, preview, production: each with its own values. Then building for production picks up production configuration without you remembering anything.
Values that differ per environment go in the profile. API URLs, feature flags, the analytics key for that environment.
Values that are genuinely sensitive go in the build service's secret storage, which keeps them out of your repository. Note this protects them from your git history, not from the shipped app - see the previous answer.
Keep the local development file for convenience, and make sure it is git-ignored and that nothing depends on it existing.
Two things to check once you have done it:
Confirm the value made it into the bundle rather than assuming. Log it once at startup in a preview build. Undefined at runtime and undefined at build time look identical from the app's side and the fix is different.
Watch out for names that are only substituted with a specific prefix. Bundlers commonly only inline variables whose names match a convention, and a value with the wrong prefix silently becomes undefined without any warning.