Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Support environment variable placeholders in configuration files

Abierto
  • ¿Algo no está bien?
#1,667 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
csharp
Área
cli, tooling

Línea de trabajo

Empieza rastreando la carga de configuración para devproxyrc.json y los archivos de configuración de los plugins; después, lee ProxyUtils.ReplaceVariables, IProxyConfiguration.Env y la ruta de reemplazo existente de MinimalPermissionsPlugin. Verifica cómo se representan los valores de entorno y la sección de configuración env antes de decidir dónde debe realizarse la resolución. La tarea está terminada cuando los marcadores de posición ${VAR_NAME} se resuelven de forma coherente en los archivos de configuración mostrados sin requerir un script de reescritura, con cobertura para marcadores de posición incrustados como la URL del issuer.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

needs peer review

Summary

Dev Proxy config files (devproxyrc.json and plugin config files like CrudApiPlugin API files) don't support environment variable placeholders. This means values that vary per environment — like Entra app client IDs or tenant IDs — must be hardcoded in config files, or users need to write scripts to patch them before running Dev Proxy.

Example: the workaround today

In the da-ristorante-api-devproxy-entra sample, we need to inject ENTRA_APP_CLIENT_ID and ENTRA_APP_TENANT_ID into the CrudApiPlugin API files. Because Dev Proxy doesn't support this, the sample includes a Node.js script that reads .env.local and rewrites the JSON config files before each run.

The config file looks like this:

{
  "entraAuthConfig": {
    "audience": "<ENTRA_APP_CLIENT_ID>",
    "issuer": "https://login.microsoftonline.com/<ENTRA_APP_TENANT_ID>/v2.0"
  }
}

And the script manually replaces those placeholders with values from env files. This works but adds friction — extra tooling, an extra build step, and mutated config files that can accidentally get committed.

What I'd like to see

Support for environment variable references in config files, for example:

{
  "entraAuthConfig": {
    "audience": "${ENTRA_APP_CLIENT_ID}",
    "issuer": "https://login.microsoftonline.com/${ENTRA_APP_TENANT_ID}/v2.0"
  }
}

When Dev Proxy loads a config file, it would resolve ${VAR_NAME} placeholders against environment variables (or the env config section).

Why this seems feasible

Dev Proxy already has closely related infrastructure:

  • Path tokens: ~appFolder and ~dataFolder are resolved via ProxyUtils.ReplacePathTokens when loading config/plugin paths
  • @dynamic tokens: used in mock responses and rate limiting headers, resolved at runtime
  • ProxyUtils.ReplaceVariables: a general-purpose string replacement utility that replaces variable references in a string given a dictionary of values
  • IProxyConfiguration.Env: the proxy configuration already exposes a Dictionary<string, string> Env property
  • MinimalPermissionsPlugin already uses ProxyUtils.ReplaceVariables(fileContents, ProxyConfiguration.Env, v => $"{{{v}}}") to resolve {VAR} placeholders in OpenAPI spec files

The pattern is already proven in plugins — it just needs to be applied when loading configuration files too.

Benefits

  • No more wrapper scripts to inject environment-specific values
  • Config files stay clean and committable (no secrets, no environment-specific values)
  • Consistent with how other tools handle this (Docker Compose, Azure Pipelines, GitHub Actions, etc.)
  • Works naturally with .env files and CI/CD environments
Lenguaje dominante
C#
Estrellas
833
Forks
90
Merge medio
18 h 41 min
PR fusionados (30 d)
45

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dotnet/dev-proxy

Todos los issues de dotnet/dev-proxy

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.