Add Support for Reading Environment Variables from .env Files

[toto6038]

Clear and concise description of the problem

Currently, tsdown allows defining compile-time environment variables through two methods: a configuration file or the --env.* <value> command-line option. However, it does not support reading environment variables from .env files yet, which makes it challenging to dynamically manage these constants. Adding this feature would enhance flexibility and streamline the workflow.

I'd be happy to help implement this feature :)

Suggested solution

1. Add Command-Line Options:
   Introduce the following new command-line options:

   • --env-file <file>: Specifies the path to the .env file to load environment variables from.
   • --env-prefix <prefix>: Defines a prefix for environment variables (default: TSDOWN).

   Additionally, allow the envPrefix option to be set in the configuration file.

2. Integrate dotenv for Environment Variable Resolution:
   During the resolution of UserConfig, use dotenv to load environment variables from the specified .env file. Apply the prefix filter (if provided) for security to ensure only relevant variables are included.

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[sxzz]

A feasible approach is to use Node's built-in process.loadEnvFile to load environment variables from the specified envFile path, and only accept variables with the envPrefix (TSDOWN_)

[toto6038]

Thanks for the heads-up! Glad we can avoid the extra dependency. I'll pick this up as soon as I'm free.

[toto6038]

@sxzz I’d like to get your thoughts on how the new --env-file option should interact with the existing --env.* flags.

Currently, there is a discrepancy in how environment variables are filtered:

• --env-file: Only loads variables prefixed with TSDOWN_.
• --env.* (CLI): Loads variables exactly as specified, without any prefix constraints.

Should we maintain this distinction, or should the behavior be unified? If both flags are used simultaneously, should CLI-defined variables (--env.*) take precedence over those found in the .env file?

[sxzz]

• Load env file, set to process.env.*
• The final result is { ...process.env (with TSDOWN_ prefix), ...env option }