typescript - Cómo usar el archivo `tsconfig.js` en lugar de `tsconfig.json`

Tengo múltiples proyectos con múltiples archivos tsconfig.json (y otros archivos de configuración) y mi objetivo es usar el mismo en cada proyecto.

Para lograr eso decidí crear un paquete npm config, con un archivo estándar tsconfig.json (y otros archivos de configuración .json).

los comandos de mi TypeScript anterior para construir mi proyecto eran tsc -p tsconfig.json --incremental y traté de cambiarlos a tsc -p tsconfig.js --incremental con un archivo tsconfig.js que se ve así:

module.exports = {
  ...require('./node_modules/@myOrg/myPackage/tsconfig.json')
};

Usando spread donde podría sobrescribir algunas propiedades si fuera necesario.

Mi idea parece ser legítima, pero no funciona, no se compila usando tsc con este archivo de configuración porque omite cada una de las propiedades del tsconfig.json (como esModuleInterop, downlevelIteration, es2015, etc...) que obviamente están en el tsconfig.json del paquete.

¿Cómo puedo lograr mi objetivo? Puede que esta técnica funcione para todos los demás archivos de configuración .json, excepto tsconfig.json, porque algunas de sus opciones son necesarias para que sea posible.

Respuesta #1

Un módulo de configuración ejecutable explícitamente no está soportado:

No estamos aceptando PRs para convertir la configuración en algo ejecutable. Esto abre una enorme caja de Pandora (¿es seguro ejecutar esto? ¿qué dependencias tiene el archivo de configuración? ¿qué supone el archivo de configuración sobre su entorno?) que preferimos que permanezca cerrada.

GitHub: Permitir archivo de configuración javascript (o typescript) <Sugerencia> (#30400)

Alternativas :

No has dicho por qué estás centralizando tu tsconfig. Si es solo por conveniencia, entonces podrías usar la opción extends para heredar opciones de configuración de otro archivo tsconfig.

Tenga en cuenta que "Todos los caminos relativos encontrados en el archivo de configuración se resolverán en relación con el archivo de configuración en el que se originaron." Por lo tanto, seguir este enfoque probablemente le impediría heredar todas las propiedades. Probablemente necesitaría proporcionar al menos algunas opciones en su archivo de configuración local (como files).

Si realmente quieres copiar tu tsconfig por completo (incluyendo las rutas de archivos relativas), entonces podrías usar una herramienta de construcción (como gulp) para copiar el tsconfig.json desde una ubicación conocida hasta la raíz de tu proyecto antes de ejecutar tsc. Estoy seguro de que puedes imaginar algunos de los problemas que esto introduciría, incluyendo que un desarrollador tendría que realizar pasos adicionales en la CLI antes de cargar el proyecto en un editor como VS Code.

Una palabra de precaución:

Una configuración base puede ser muy útil para estandarizar tus compilaciones, pero existe el riesgo de que causes más problemas de los que resuelves a largo plazo. Es importante encontrar un equilibrio. Heredar demasiado de una fuente externa endurecerá tu proyecto, lo que dificultará adaptarse a cambios ambientales o nuevas tecnologías. Podrías encontrarte necesitando ajustar la configuración base por el bien de un proyecto, pero esos ajustes podrían ser incompatibles con otro. O podrías encontrarte constantemente sobrescribiendo las mismas propiedades de tu configuración base porque tus preferencias cambiaron, pero los proyectos antiguos todavía dependen de esas opciones anteriores. Podrías solucionar esto mediante versionado o etiquetado, pero entonces ¿qué has ganado? Aún tienes más de una configuración, simplemente son más difíciles de encontrar y usar. Hay buenas razones para mantener la configuración de tu proyecto con tu proyecto.

Heredar de una configuración común no es necesariamente algo malo, pero la dependencia excesiva de la herencia, en mi opinión, causará problemas a largo plazo que son más difíciles de resolver que simplemente copiar tu tsconfig de una plantilla.