Rollup-plugin-typescript2: La opción predeterminada de tsconfig "incluir" es anulada por el índice del tsconfig.json original.

esto hace que usar include imposible ya que nunca se sabe cuánto tiempo estará la matriz en el tsconfig.json

Cosa interesante,
si muevo typescript2 config include opción de tsconfigDefaults a tsconfigOverride
anulará la opción original tsconfig.json include por índice.

es decir, es exactamente lo contrario
pero tambien es muy malo

Y una cosa más
después de algunas investigaciones adicionales
Me di cuenta de que el mismo comportamiento también es relevante para otras propiedades de la matriz.

Así que he abordado este problema antes en https://github.com/jaredpalmer/tsdx/pull/666#discussion_r404847759 , y por ese problema, así es como funciona la fusión profunda de _.merge . Es una fusión profunda, por lo que fusiona las matrices y el índice es el único identificador de la matriz. Puede ser _ inesperado_ pero es una fusión profunda, así es como funcionan las fusiones profundas.

De hecho, no concatena estas propiedades, sino que reemplaza los valores en la celda de índice ,

• En cambio, hacer un append / concat no se fusionaría en absoluto y no daría forma de sobrescribir con tsconfig en absoluto. Eso me parece un comportamiento incorrecto.
• En cambio, hacer una fusión superficial simplemente sobrescribiría lo que está en los valores predeterminados, que tampoco estoy seguro de que sea el comportamiento esperado, pero es similar a cómo funciona tsconfig con respecto a exclude : si agrega un exclude , sobrescribe los valores predeterminados.

Podría escribir un PR para hacer una fusión superficial en solo include y exclude , pero eso sería _muy_ romper un cambio; No tengo idea de cómo eso podría afectar a todos los usuarios intermedios. Idk si los usuarios de TSDX esperan una fusión superficial o profunda, pero interrumpiría su uso si esperan una fusión profunda.

si muevo typescript2 config include opción de tsconfigDefaults a tsconfigOverride
anulará la opción original tsconfig.json include por índice.

es decir, es exactamente lo contrario

Sí, así es como se supone que funciona tsconfigOverride , es una anulación.

Me di cuenta de que el mismo comportamiento también es relevante para otras propiedades de la matriz.

Sí, así es como _.merge hace una fusión profunda, por lo que cualquier cosa en tsconfig que sea una matriz tiene el mismo cambio.

@ agilgur5 gracias por la respuesta!

1) Desde mi punto de vista, este comportamiento hace que la configuración sea totalmente inútil. No podemos garantizar la confiabilidad de la configuración si estamos atados a una posición en la matriz.

2) De hecho, sería un cambio radical. Pero si nuestra dirección es lograr el mejor DX , entonces deberíamos dejar esto claro y útil.

Tengo un truco en mi bolsillo para manejar esto, pero parece ruidoso desde la perspectiva del código limpio: solo lea tsconfig , obtenga la propiedad include y concatene esto con mi matriz. Parece que debería ser más fácil.

Mi sugerencia:
1) por defecto: recopile la propiedad predeterminada y concatene con el tsconfig original; eliminar duplicados.
2) para anulación: aplique solo la opción de anulación

Los valores predeterminados normalmente no se concatenan cuando se anulan, se anulan. Y como mencioné anteriormente, la concatenación hace que sea _imposible_ anular el valor predeterminado con tsconfig . Eso me suena a un comportamiento incorrecto de muchas maneras, así que lo desaconsejo enérgicamente.

Creo que todas las opciones son confusas, no estoy seguro de estar de acuerdo en que alguna de estas sea el "mejor DX". Una fusión superficial es lo más parecido a cómo funciona tsconfig con su exclude predeterminado, pero eso no viene sin concesiones.
En general, es necesario pensar mucho en los cambios de ruptura, razón por la cual mencioné eso: los efectos posteriores no son triviales; TSDX también tendría que lanzar un cambio importante para actualizar dicho cambio.

@ agilgur5 bien, entonces no puedo usar el valor predeterminado o anular en absoluto.
¿Causa? No hay garantía de que no se escriba ningún valor en ese índice.
Además, puede sortear todo a través de undefined como valor de la matriz y agregar aún más el valor necesario. ¿Y resulta que hay un vacío en este sistema? Simplemente genial.

El caso:

1. Quiero agregar mis tipificaciones d.ts adicionales dentro de la propiedad de configuración "include".
2. El usuario pone su directorio src dentro de "incluir" con otro proyecto específico d.ts mecanografiado fuera de src .

1. ['config.d.ts`]
   2. ['Src', 'some.d.ts', 'otro.d.ts']
2. Resultado: ['src', 'some.d.ts', 'otro.d.ts']

Como puede ver, no hay forma de configurar esto correctamente. Debería leer tsconfig.json, obtener su propiedad "include" y fusionar esto en ['src', 'some.d.ts', 'another.d.ts', 'config.d.ts'].
Y creo que esto es una completa sobrecarga.

Mientras tanto, descubrí cuál es el problema. Es posible que otros no lo resuelvan y dediquen su valioso tiempo a descubrir qué no les funciona.
Y después de su primer mensaje, ya he visto al menos 2 problemas relacionados. Y seguirá y seguirá.

Lo veo para que si dejamos todo como está, entonces no puedo usarlo, es una caja negra para mí porque no puedo garantizar nada.
No hay lugar para preferencias personales "como" / "no me gusta".
Esto puede usarse o no. Y no puede.

No tengo ningún problema en reunir las opiniones de otras personas involucradas en esto.
Y una cosa más, no tengo problemas para quedarme con la solución actual, tengo el truco descrito anteriormente, que estoy listo para seguir. Pero no entiendo cuál es el problema de hacer que esta solución sea transparente, sin estar atado al hecho de que implicará cambios rotundos.

Quiero decir, estás dando tu propia preferencia aquí, mientras que ya he dado varias opciones diferentes. Ya he dicho dos veces por qué esa preferencia, la concatenación, es fundamentalmente rota, igualmente poco intuitiva y nada "transparente". Para repetir, la concatenación no es sólo un cambio rotundo, literalmente hace que las cosas primordiales sean imposibles . Repetiré de nuevo, imposible .
Ser imposible anular con la concatenación no es una "preferencia", eso es un hecho.

Una vez más, un "valor predeterminado" que no se puede anular no es un valor predeterminado, es un requisito. Cambiar un "predeterminado" a un requisito no tiene sentido y es un comportamiento incorrecto.

Puede anular la fusión profunda ahora mismo, no puede anular una concatenación. Hacer imposible un caso de uso existente no tiene sentido.

También ya he dado una opción alternativa dos veces que no está fundamentalmente rota, que es una fusión superficial. Lo repetiré de nuevo, puedes usar una combinación superficial para resolver esto también.
Si eso es mejor es discutible. Hay compensaciones para todo.

He contribuido aquí para corregir errores antes (sé que es _.merge porque he leído el código base) y una biblioteca que mantengo constituye una parte significativa del uso de esta biblioteca (~ 10%), estoy no solo hacer puntos de conversación aquí ...

Sin mencionar que esto se puede resolver sin cambios importantes: puede agregar una nueva opción por tsconfigConcat o tsconfigDefaultShallow etc.

Decir que solo hay una opción y que debe romperse y debe hacer que el caso de uso existente sea imposible simplemente no es cierto.

Creo que tendremos que romper cosas sin importar lo que hagamos aquí. Para que se comporte de acuerdo con el espíritu de la documentación y los nombres de las propiedades, básicamente debería hacer esto:

• tsconfigDefaults : este es el objeto en el que todo lo que se muestra a continuación se fusionará profundamente
• tsconfig : este es el objeto que obtenemos del mecanografiado, después de sus propias importaciones y todo. Todos los valores aquí reemplazan los valores en tsconfigDefaults . Todos los arreglos aquí están concatenados con arreglos en tsconfigDefaults .
• tsconfigOverride - esta es la opción nuclear. Los objetos todavía se fusionan profundamente, pero los arreglos aquí reemplazan a los arreglos al por mayor. Entonces, si proporciona una matriz de inclusión vacía aquí, el tsconfig final no tendrá ninguna inclusión.

¿Cubrirá eso todos los casos que queremos apoyar (después de que los usuarios realicen los cambios apropiados), o me falta algo?

@ezolenko suena increíble y tiene mucho sentido de usar

@ezolenko No estoy seguro de por qué tienes que romper cosas. Ya he dado opciones que no se rompen.

No estoy seguro de cómo lo que ha enumerado refleja "el espíritu de la documentación y los nombres de las propiedades" porque los documentos dicen:

El objeto pasado como tsconfigDefaults se fusionará con el tsconfig.json cargado. La configuración final pasada a mecanografiado será el resultado de los valores en tsconfigDefaults reemplazados por los valores en tsconfig.json cargados
[...]
Esta es una combinación profunda (los objetos se combinan , las matrices se concatenan, las primitivas se reemplazan , etc.), aumente verbosity a 3 y busque parsed tsconfig si obtiene algo inesperado.

Dice "fusionado", "reemplazado" y "fusión profunda", todo lo cual significa reemplazar y anular el predeterminado. Hay una única referencia a "concatenados" que es _diferente del resto_, pero una fusión profunda _no_ de hecho concatena. 5 referencias dicen una cosa y una sexta es incorrecta. Para mí, eso suena a que la sexta referencia que es incorrecta debería corregirse, no las 5 correctas cambiadas a la sexta incorrecta.

lodash es el estándar de facto y su definición de fusión es _no_ para concatenar. La definición de valores predeterminados es que se anulan cuando establece el mismo valor de propiedad, _no_ concatenado:

_.defaults({ a: ['a'] }, { a: ['b', 'c'] });
// => {a: ['a']}
_.defaultsDeep({ a: ['a'] }, { a: ['b', 'c'] });
// => {a: ['a', 'c']}

Si desea agregar una opción de concatenación, creo que debería ser una configuración separada, porque tampoco coincide con más de 5 referencias en los documentos y porque eso simplemente no es lo que significan los valores predeterminados, ni en la definición ni en el uso en ningún Biblioteca.

También rompe la simetría con tsconfigOverride así como sus propios documentos:

• tsconfigOverride : {}
  Ver tsconfigDefaults .

Espero que se anulen los valores predeterminados, esa es la definición, hacer que se concatenen en su lugar es increíblemente poco intuitivo. Una fusión profunda puede no ser intuitiva para las matrices, pero los documentos dicen claramente que es una fusión profunda y entendí rápidamente que ese era el problema porque los índices eran relevantes. Tampoco informé un error porque eso es lo que dicen los documentos e incluso el enlace a la fusión profunda: ese es el comportamiento previsto, no un error.

Como he dicho, la fusión superficial de las matrices puede ser más intuitiva, ya que así es como funciona realmente tsconfig _itself_. Como he vinculado anteriormente, tsconfig _itself_ no se concatena cuando agrega un exclude , anula el exclude .

Por lo tanto, concatenar no coincide con más de 5 referencias en los documentos, la definición de fusión, la definición de valores predeterminados ni el propio comportamiento de tsconfig . Y rompe la simetría y la documentación de otras opciones. No estoy seguro de cómo eso es intuitivo.

Y como he dicho varias veces, convertirlo en una concatenación poco intuitiva en lugar de anular hace que ciertos casos de uso sean _imposibles_ . Aquí está el uso de TSDX:

https://github.com/jaredpalmer/tsdx/blob/17ffcd215f78a4e9d6936644cbeab332f6439088/src/createRollupConfig.ts#L149 -L178

La intención es que si agrega su propio exclude , anule los valores predeterminados que hemos establecido. Los valores predeterminados solo se aplican si no ha establecido el nombre de la propiedad, al igual que cualquier otro nombre de propiedad (nuevamente, esa es la definición de valores predeterminados y cómo funcionan los valores predeterminados en todas las bibliotecas).

Si tuviera que cambiar eso para concatenar, entonces el usuario ahora no tiene forma de anular nuestro exclude predeterminado, es _imposible_ que anule el predeterminado. También enviamos el tsconfig predeterminado de exclude , así que esto también hace que sea _imposible_ anular el tsconfig predeterminado de tsconfig , aunque tsconfig _itself_ te lo permite que.

No estoy seguro de por qué estoy hablando como un disco rayado aquí repitiendo _definiciones existentes_ y _uso existente_ en el _ ecosistema completo _.

@ agilgur5

Y como he dicho varias veces, lo que lo convierte en una concatenación muy poco intuitiva en lugar de anular
hace que ciertos casos de uso sean imposibles. Aquí está el uso de TSDX:
https://github.com/jaredpalmer/tsdx/blob/17ffcd215f78a4e9d6936644cbeab332f6439088/src/createRollupConfig.ts#L149 -L178

Esta configuración se puede interrumpir fácilmente y no entiendo por qué esto no es obvio para usted. No quiero que mi biblioteca sea frágil, y por eso creé este problema.

Lo curioso es que @ezolenko y yo ya te hemos propuesto una solución que te ayudará a proteger, incluido TSDX, pero aún te resistes.

Los valores predeterminados solo se aplican si no ha establecido el nombre de la propiedad

Estoy de acuerdo con el comportamiento

imposible para ellos anular el valor predeterminado

La pregunta es, ¿por qué el usuario debería tener acceso a lo que el autor de la biblioteca prohibió?

Debemos aprovechar la configuración de tsconfig que no se puede sobrescribir, pero al mismo tiempo, debemos dar la oportunidad de expandir nuestros ajustes preestablecidos. Y este es el punto principal.

La solución radica únicamente en el diseño de la nueva API.

Esta configuración se puede interrumpir fácilmente y no entiendo por qué esto no es obvio para usted. No quiero que mi biblioteca sea frágil, y por eso creé este problema.

Estás sacando palabras de mi boca que ni remotamente dije. No dije que no pudiera y tampoco dije que no fuera frágil. Acabo de decir que _su_ solución no coincide con ninguna _definición existente_ ni _uso existente_ en el _ecosistema completo_ de valores predeterminados ni los propios documentos. Romper toda la definición de incumplimiento es claramente un comportamiento incorrecto.
Como he dicho varias veces, mi sugerencia fue combinar matrices superficiales en su lugar, es decir, tsconfig anula tsconfigDefaults como lo hace para todas las propiedades que no son de matriz y como funciona tsconfig _itself_ .
Como he dicho varias veces, eso se puede hacer con un cambio rotundo o un cambio rotundo.

Por favor, no me saques las palabras de la boca. Me he repetido muchas veces, por favor lea las cosas reales que escribí en lugar de inventarlas.

La pregunta es, ¿por qué el usuario debería tener acceso a lo que el autor de la biblioteca prohibió?

tsconfig no prohibió eso, TSDX no prohibió eso, y rollup-plugin-typescript2 tampoco prohibió eso, así que no sé a qué te refieres.

Debemos aprovechar la configuración de tsconfig que no se puede sobrescribir, pero al mismo tiempo, debemos dar la oportunidad de expandir nuestros ajustes preestablecidos. Y este es el punto principal.

La solución radica únicamente en el diseño de la nueva API.

Sí, puede agregar una opción tsconfigConcat para esto, y esa sería una "nueva API". Romper la API actual reinventando la definición completa de predeterminado crea un conjunto completo de nuevos problemas y un nuevo comportamiento poco intuitivo. Excepto que, si bien una combinación profunda puede no ser intuitiva para las matrices, sigue siendo un comportamiento _correcto_. Una concatenación es simplemente un comportamiento incorrecto, porque eso no es lo que significa predeterminado.

Un tsconfigConcat resolvería su caso de uso y es más intuitivo porque literalmente tiene concat en el nombre y eso es exactamente lo que hace.
Cambiar tsconfigDefaults para que signifique "concatenación" no es porque eso, por quinta vez, _no es lo que significa por defecto_.

predeterminado = \ = concatenación. Esa no es mi opinión, esa es la definición.

@ agilgur5 lo siento, pero no pueden tomarlo en serio.
Cada una de tus frases es controvertida, estoy cansado de eso.

Simplemente sostengo que la API actual no permite ningún trabajo adecuado con ella, y esta es la razón para cambiarla.
No voy a continuar con esto más.

Bueno, no quité las palabras de la boca de la gente, no leí sus palabras reales, inventé cosas, ataqué el carácter de un colaborador, proporcioné 0 enlaces, di 0 alternativas y solo consideré una sola opción y ninguna otra, ese eras tú. .

Si desea atacar a un colaborador que solo está tratando de ser útil y está brindando definiciones reales, casos de uso reales y alternativas reales, supongo que esa es su perogativa: encogerse de hombros:

Creo que tenía la impresión de que lodash merge de hecho fusionaría matrices (intercalarlas o algo así) cuando estaba escribiendo esa parte. O ni siquiera estaba prestando atención a lo que sucede con las matrices. Dado que aparentemente sobrescribe el contenido de las matrices usando índices como nombres de elementos (¿verdad? ¿Es esto de javascript acerca de las matrices que originalmente no son matrices verdaderas, sino que son diccionarios que tienen números para claves?), Nuestra documentación en este momento miente.

Idealmente, las opciones de tsconfigs por defecto / main / override deberían permitir la personalización de todos los parámetros, tanto valores escalares como matrices, de la misma forma nada sorprendente. La forma rápida de reemplazar elementos de matriz basada en el índice tiene un inconveniente importante: no puede crear matrices dispersas literales (¿tal vez una matriz de relleno con un montón de undefined s?). Eso significa que la configuración acumulada debe construirse dinámicamente, y tsconfig, al ser un archivo json, no puede hacerlo en absoluto.

Incluso con matrices literalmente dispersas, reemplazar elementos basados ​​en índice es demasiado frágil.

Por otro lado, la concatenación es sorprendente, si nada más suele comportarse de esta manera. Y por sí solo no permite la eliminación de valores anteriores.

Cambiar entre concatenar y reemplazar como propuse originalmente es doblemente sorprendente.

Cambiar ambas fusiones para reemplazar matrices al por mayor como propuso @ agilgur5 es probablemente una opción menos sorprendente, permitirá eliminar valores, a expensas de tener que repetir los valores que uno quiere mantener. Sin embargo, sigue siendo un cambio importante y la gente tendrá que volver a escribir sus configuraciones para eso (consulte https://xkcd.com/1172/).

Podemos cambiar el comportamiento de esas opciones o crear un nuevo conjunto y desaprobar las opciones existentes con una advertencia.

(lo siento si me perdí un punto importante en alguna parte, solo escaté todo el hilo)

@ezolenko veo el siguiente camino

Veamos la situación y la motivación:
El desarrollador desea agregar algunas configuraciones necesarias para mecanografiar a través del complemento acumulativo.
En este caso, no debemos evitar que el desarrollador agregue configuraciones de manera segura y no perder ninguna otra configuración al fusionar la configuración y las configuraciones acumuladas.

¿Qué nos dice esto? Empecemos por la semántica:

Como dije antes

Estoy de acuerdo con el comportamiento predeterminado. Tiene sentido aplicar la configuración predeterminada solo cuando tsconfig no tiene las propiedades correspondientes ...

Podemos rediseñar esto por completo.

Mis sugerencias son:

1. Aplicar propiedades tsconfigDefaults cuando el tsconfig no tiene propiedades correspondientes.
2. tsconfigOverride debería encargarse de esto.
   2.1 Debería funcionar como antes con valores escalares.
   2.2 Debería concatenar las propiedades de la matriz. (probablemente esto no debería romper nada y debe cumplir con la motivación de configuración)

Solo trato de evitar la tercera opción adicional rpt2, porque complicará esta API en al menos un 50% y cualquier desarrollador dejará de entender esto.

@ agilgur5 Es maravilloso que la realidad y las palabras que dices no sean lo mismo.

Además, gracias a la notificación por correo electrónico, leí el mensaje original, y no lo edité 8 veces, para parecer mejor a los ojos de la gente.
Nadie quería atacarte, además, nadie lo hizo.
Simplemente se le pidió que dejara de ser agresivo y dejara de escribir discursos contradictorios en este hilo.

• 0 enlaces: dediqué mucho tiempo a comprender el problema, describirlo completamente, dar ejemplos e incluso capturas de pantalla. Y además, incluso estudié tu TSDX, y te dije que tu configuración es frágil, porque la revisé. Y lo más importante, no guardé silencio, sino que creé este problema para escalar el problema para aquellos que se enfrentan a esto.
• 0 alternativas - lea atentamente. Empecé a ofrecer soluciones desde el primer mensaje.
• Sacando palabras - cálmate y deja de ser narcisista al menos en este hilo, es desagradable para mí trabajar así.

@maktarsis, en su enfoque, ¿cómo podría el desarrollador eliminar las entradas de inclusión o exclusión de tsconfig? El escenario es: tiene un tsconfig.json que se usa en otro lugar, desea usarlo en el resumen sin tocar el propio json, pero desea eliminar una línea de la matriz de exclusión por alguna razón.

@ezolenko Aunque entendí tu.

Naturalmente, como se discutió anteriormente, esto no será posible.
Pero estamos hablando de posibilidades más que de motivación.

Todavía no veo situaciones en las que necesitemos reescribir la exclusión.
Sin embargo, soy de la opinión de que no es necesario sobrescribir el "excluir" de los desarrolladores. En otras palabras, no puedo imaginar por qué.
Es necesario comprender el motivo de "por alguna razón".

Si desea tener esta posibilidad en cualquier caso, debe proporcionar una API adicional para la concatenación.
Pero como comprenderá, creo que podría no ser reclamado y simplemente innecesario.
La exclusión de algo de "excluir" puede no ser necesaria en absoluto, pero si vamos al otro lado, complicamos la comprensión de la configuración.

Necesitamos ambos, agregar algo a la matriz que no está allí y eliminar algo de ella. Con la fusión superficial, tanto la adición como la eliminación se realizan replicando toda la matriz (con cambios) en un nivel superior. No muy conveniente, pero utilizable.

Este también es el caso de "esModuleInterop": true que hizo que mi biblioteca no funcionara en algunos entornos.

Opción de compilador inútil en config.json:

{
   ...
  "compilerOptions": {
       ...
      "esModuleInterop": true,
  },
}

Opción de compilador útil en rollup-config:

typescript({
    useTsconfigDeclarationDir: true,
    tsconfigOverride: {
      esModuleInterop: true,
    },
  }),

La primera sugerencia de

Aplique las propiedades tsconfigDefaults cuando el tsconfig original no tenga las propiedades correspondientes.

^ El comentario anterior parece no tener relación, ya que no es para include o matrices. La "sugerencia" mencionada es lo que ya hace tsconfigDefaults .
También yo, y TSDX, usamos esModuleInterop gran medida, así que sé que funciona en tsconfig.json , no estoy seguro de lo que se suponía que significaba ese comentario. A la configuración publicada también le falta compilerOptions , debería ser:

js typescript({ useTsconfigDeclarationDir: true, tsconfigOverride: { compilerOptions: { esModuleInterop: true, }, }, }),

Pero eso anularía y funcionaría según lo previsto.

Observando aquí que la fusión superficial se ha mencionado anteriormente en este repositorio varias veces: # 86 (que menciona el comportamiento de fusión superficial de TS como lo hice aquí), https://github.com/ezolenko/rollup-plugin-typescript2/issues/72 #issuecomment -383242460 y https://github.com/ezolenko/rollup-plugin-typescript2/issues/208#issuecomment -594237841