Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Proposal]: Opt-in Preservation of Public Variables in .env to .example.env Syncing #52

Open
MendyLanda opened this issue Jul 19, 2023 · 0 comments

Comments

@MendyLanda
Copy link

Feature Proposal: Enhancements for Syncing .env Files

Objective:

Improve the functionality of our CLI tool that synchronises .env files to .example.env files by providing an escape mechanism to preserve specific values for public variables.

Problem:

Currently, all variables in the .example.env file exist as empty strings after the syncing process. It would be helpful for public variables to retain their values.

Proposed Solution:

I thought of two way to achive this:

  1. Public Prefix Preservation: Allow users to specify a custom or default prefix for variable names that they want to remain public. Any variable with this prefix will retain its value during the sync process.

    CLI Example:

    sync-dotenv --preserve-public-prefix=NEXT_PUBLIC

    In this example, any variable starting with NEXT_PUBLIC will keep its original value in the .example.env file.

    Default behavior (when flag is used without a value): An error will be thrown requesting for a prefix input.

  2. Keyword Comment Preservation: Allow users to mark variables for preservation using a default or custom keyword comment at the end of the line.

    .env file Example:

    SENTRY_URL='https://example.ingest.sentry.io/example' #SYNC_VALUE

    CLI Example:

    sync-dotenv --preserve-keyword-comment=SYNC_VALUE

    In this example, any variable line ending with #SYNC_VALUE will keep its original value in the .example.env file.

    Default behavior (when flag is used without a value): An error will be thrown requesting for a keyword input.

Considerations:

  1. Need to ensure these changes are well documented in the CLI help text.

  2. Need to provide examples in the readme for the new flag and potential use cases.

  3. Error handling needs to be designed carefully to provide meaningful error messages, especially when the new flags are used without necessary inputs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant