Rollup-plugin-typescript2: L'option tsconfig par défaut "include" est remplacée par l'index du fichier tsconfig.json d'origine

cela rend l'utilisation de include impossible car on ne sait jamais combien de temps le tableau restera dans le tsconfig.json

Chose intéressante,
si je déplace l'option typescript2 config include de tsconfigDefaults à tsconfigOverride
il remplacera l'option originale tsconfig.json include par index.

c'est-à-dire que c'est exactement le contraire
mais c'est aussi très mauvais

et encore une chose
après quelques investigations complémentaires
J'ai réalisé que le même comportement est également pertinent pour d'autres propriétés de tableau

J'ai donc déjà rencontré ce problème dans https://github.com/jaredpalmer/tsdx/pull/666#discussion_r404847759 , et par ce problème, c'est exactement comme cela que fonctionne la fusion profonde de _.merge . C'est une fusion profonde donc elle fusionne les tableaux et l'index est le seul identifiant du tableau. C'est peut-être inattendu, mais c'est une fusion profonde, c'est ainsi que fonctionnent les fusions profondes.

En fait, il ne concatène pas ces propriétés, mais remplace les valeurs de la cellule d'index ,

• Au lieu de cela, faire un ajout / concat ne serait pas du tout une fusion, et ne donnerait aucun moyen d'écraser avec tsconfig du tout. Cela me semble être le mauvais comportement.
• Au lieu de cela, faire une fusion superficielle écraserait simplement ce qui est par défaut, ce qui, je ne suis pas sûr, soit le comportement attendu non plus, mais c'est similaire à la façon dont tsconfig fonctionne en ce qui concerne exclude : si vous ajoutez un exclude , il écrase les valeurs par défaut.

Je pourrais rédiger un PR pour faire une fusion superficielle sur seulement include et exclude , mais ce serait _pretty_ rupture d'un changement; Je n'ai aucune idée de l'impact que cela pourrait avoir sur tous les utilisateurs en aval. Idk si les utilisateurs de TSDX s'attendent à une fusion superficielle ou profonde, mais cela interromprait leur utilisation s'ils s'attendaient à une fusion profonde.

si je déplace l'option typescript2 config include de tsconfigDefaults à tsconfigOverride
il remplacera l'option originale tsconfig.json include par index.

c'est-à-dire que c'est exactement le contraire

Oui, c'est ainsi que tsconfigOverride est censé fonctionner, c'est un remplacement.

J'ai réalisé que le même comportement est également pertinent pour d'autres propriétés de tableau

Oui, c'est ainsi que _.merge effectue une fusion profonde, donc tout ce qui est dans tsconfig qui est un tableau a le même changement.

@ agilgur5 merci pour la réponse!

1) De mon point de vue, ce comportement rend la configuration totalement inutile. Nous ne pouvons pas garantir la fiabilité de la configuration si nous sommes liés à une position dans le tableau.

2) En effet, ce serait un changement radical. Mais si notre direction est d'obtenir le meilleur DX , alors nous devons rendre cette chose claire et utile.

J'ai une astuce dans ma poche pour gérer cette chose, mais cela semble bruyant du point de vue du code propre - il suffit de lire tsconfig , d'obtenir la propriété include et de la concaténer avec mon tableau. Il semble que cela devrait être plus facile.

Ma suggestion:
1) par défaut - collecter la propriété par défaut et concaténer avec le tsconfig d'origine; supprimer les doublons.
2) pour le remplacement - appliquer uniquement l'option de remplacement

Les valeurs par défaut ne se concaténent normalement pas lorsqu'elles sont remplacées, elles sont remplacées. Et comme je l'ai mentionné ci-dessus, la concaténation rend _impossible_ le remplacement de la valeur par défaut avec un tsconfig . Cela me semble être un mauvais comportement à bien des égards, alors je déconseille fortement cela.

Je pense que toutes les options sont déroutantes, je ne suis pas sûr d'être d'accord pour dire que l'une d'entre elles est le "meilleur DX". Une fusion superficielle est la chose la plus proche de la façon dont tsconfig fonctionne avec sa valeur par défaut exclude , mais cela ne vient pas sans compromis.
En général, les changements de rupture nécessitent beaucoup de réflexion, c'est pourquoi j'ai soulevé cela - les effets en aval ne sont pas triviaux; TSDX devrait également publier un changement de rupture pour mettre à jour un tel changement.

@ agilgur5 très bien, alors je ne peux pas utiliser le défaut ou le remplacement du tout.
Cause? Il n'y a aucune garantie qu'aucune valeur ne sera écrite sur cet index.
De plus, vous pouvez tout contourner via undefined en tant que valeur du tableau, et en ajoutant davantage la valeur nécessaire. Et il s'avère qu'il y a une lacune dans ce système? Tout simplement génial.

L'affaire:

1. Je veux ajouter mes saisies d.ts supplémentaires dans la propriété de configuration "include".
2. L'utilisateur met son src dir à l'intérieur de "include" avec un autre typage d.ts spécifique au projet en dehors de src .

1. ['config.d.ts`]
   2. ['src', 'some.d.ts', 'another.d.ts']
2. Résultat: ['src', 'some.d.ts', 'another.d.ts']

Comme vous pouvez le voir, il n'y a aucun moyen de configurer cela correctement. Je devrais lire tsconfig.json, récupérer sa propriété "include" et la fusionner dans ['src', 'some.d.ts', 'another.d.ts', 'config.d.ts'].
Et je pense que c'est une surcharge complète.

Pendant ce temps, j'ai compris quel était le problème. D'autres peuvent ne pas le comprendre et passer leur temps précieux à comprendre ce qui ne fonctionne pas pour eux.
Et après votre premier message, j'ai déjà vu au moins 2 problèmes liés. Et cela continuera encore et encore.

Je le vois de telle sorte que si on laisse tout tel quel, alors je ne peux pas l'utiliser, c'est une boîte noire pour moi parce que je ne peux rien garantir.
Il n'y a pas de place pour les préférences personnelles "comme" / "je n'aime pas".
Cela peut être utilisé ou non. Et ça ne peut pas.

Je n'ai aucun problème à recueillir les opinions des autres qui sont impliqués dans cela.
Et encore une chose, je n'ai aucun problème pour rester avec la solution actuelle, j'ai le hack décrit ci-dessus, auquel je suis prêt à m'en tenir. Mais je ne comprends pas quel est le problème de rendre cette solution transparente, sans être liée au fait qu'elle impliquera des changements de rupture.

Je veux dire, vous donnez votre propre préférence ici alors que j'ai déjà donné plusieurs options différentes. J'ai déjà dit deux fois pourquoi cette préférence, la concaténation, est fondamentalement brisée, de la même manière peu intuitive et pas du tout "transparente". Pour répéter, la concaténation n'est pas _ simplement_ un changement de rupture, elle rend littéralement les choses impossibles . Je vais répéter, impossible .
L’ impossibilité de passer outre à la concaténation n’est pas une «préférence», c’est un fait.

Encore une fois, une "valeur par défaut" qui ne peut pas être remplacée n'est pas une valeur par défaut, c'est une exigence. Changer une "valeur par défaut" en une exigence n'a pas de sens et constitue un mauvais comportement.

Vous pouvez remplacer la fusion profonde dès maintenant, vous ne pouvez pas remplacer une concaténation. Rendre impossible un cas d'utilisation existant n'a pas de sens.

J'ai également déjà donné deux fois une option alternative qui n'est pas fondamentalement cassée, ce qui est une fusion superficielle. Je le répète, vous pouvez également utiliser une fusion superficielle pour résoudre ce problème.
Que ce soit mieux est discutable. Il y a des compromis à tout.

J'ai déjà contribué ici à corriger des bogues (je sais que c'est _.merge parce que j'ai lu la base de code) et une bibliothèque que je gère représente une part importante de l'utilisation de cette bibliothèque (~ 10%), je suis pas seulement faire des points de discussion ici ...

Sans oublier que cela peut être résolu sans changements majeurs - vous pouvez ajouter une nouvelle option pour tsconfigConcat ou tsconfigDefaultShallow etc.

Dire qu'il n'y a qu'une seule option et qu'elle doit être cassante et doit rendre impossible le cas d'utilisation existant n'est tout simplement pas vrai.

Je pense que nous devrons casser des choses quoi que nous fassions ici. Pour le faire se comporter selon l'esprit de la documentation et des noms de propriétés, il devrait faire essentiellement ceci:

• tsconfigDefaults - c'est l'objet que tout ci-dessous sera profondément fusionné dans
• tsconfig - c'est l'objet que nous obtenons de dactylographié, après ses propres importations et tout. Toutes les valeurs ici remplacent les valeurs dans tsconfigDefaults . Tous les tableaux ici sont concaténés avec des tableaux dans tsconfigDefaults .
• tsconfigOverride - c'est l'option nucléaire. Les objets sont toujours profondément fusionnés, mais les tableaux remplacent ici les tableaux en gros. Donc, si vous fournissez un tableau d'inclusion vide ici, tsconfig final n'aura aucune inclusion du tout.

Cela couvrira-t-il tous les cas que nous souhaitons prendre en charge (une fois que les utilisateurs ont apporté les modifications appropriées), ou est-ce que je manque quelque chose?

@ezolenko semble incroyable et a beaucoup de sens à utiliser

@ezolenko Je ne sais pas pourquoi tu dois casser des choses? J'ai déjà proposé des options insécables.

Je ne sais pas comment ce que vous avez répertorié reflète "l'esprit de la documentation et des noms de propriété", car la documentation dit:

L'objet passé comme tsconfigDefaults sera fusionné avec tsconfig.json chargé. La configuration finale passée au typographie sera le résultat de valeurs dans tsconfigDefaults remplacées par des valeurs dans tsconfig.json chargé
[...]
Il s'agit d'une fusion profonde (les objets sont fusionnés , les tableaux sont concaténés, les primitives sont remplacées , etc.), augmentez verbosity à 3 et cherchez parsed tsconfig si vous obtenez quelque chose d'inattendu.

Il dit «fusionné», «remplacé» et «fusion profonde», ce qui signifie remplacer et remplacer la valeur par défaut. Il y a une seule référence à "concaténé" qui est "différente du reste", mais une fusion profonde ne "concatène pas" en fait. 5 références disent une chose et une 6e est incorrecte. Pour moi, cela ressemble à la 6ème référence qui est incorrecte doit être corrigée, pas les 5 correctes changées en 6ème incorrecte.

lodash est le standard de facto et sa définition de merge est _pas_ à concaténer. La définition des valeurs par

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

Si vous souhaitez ajouter une option de concaténation, je pense que cela devrait être une configuration distincte, car elle ne correspond pas non plus à plus de 5 références dans la documentation et parce que ce n'est tout simplement pas ce que les valeurs par défaut signifient, ni dans la définition ni dans l'utilisation dans aucun bibliothèque.

Il brise également la symétrie avec tsconfigOverride ainsi que ses propres documents:

• tsconfigOverride : {}
  Voir tsconfigDefaults .

Je m'attends à ce que les valeurs par défaut soient remplacées, c'est la définition, les faire concaténer à la place est incroyablement peu intuitif. Une fusion profonde peut être peu intuitive pour les tableaux, mais la documentation dit clairement qu'il s'agit d'une fusion profonde et j'ai vite compris que c'était le problème car les index étaient pertinents. Je n'ai pas non plus signalé de bogue car c'est ce que disent les documents et même un lien vers une fusion profonde - c'est un comportement prévu, pas un bogue.

Comme je l'ai dit, la fusion superficielle des tableaux peut être plus intuitive, car c'est ainsi que fonctionne réellement tsconfig _itself_. Comme je l'ai mentionné ci-dessus, tsconfig _itself_ ne concatène pas lorsque vous ajoutez un exclude , il remplace le exclude existant.

Donc concaténer ne correspond pas déjà à plus de 5 références dans la documentation, à la définition de la fusion, à la définition des valeurs par défaut, ni au comportement de tsconfig . Et cela brise la symétrie et les documents d'autres options. Je ne sais pas comment cela est intuitif.

Et comme je l'ai dit plusieurs fois, en faire une concaténation très peu intuitive au lieu de surcharger rend certains cas d'utilisation _impossible_ . Voici l'utilisation de TSDX:

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

L'intention est que si vous ajoutez votre propre exclude , il remplace les valeurs par défaut que nous avons définies. Les valeurs par défaut ne sont appliquées que si vous n'avez pas défini le nom de propriété, comme tout autre nom de propriété (encore une fois, c'est la définition des valeurs par défaut et comment les valeurs par défaut fonctionnent dans toutes les bibliothèques).

Si vous deviez changer cela pour concaténer, alors l'utilisateur n'a plus aucun moyen de remplacer notre valeur par défaut exclude , il est _impossible_ pour eux de remplacer la valeur par défaut. Nous expédions également la tsconfig par défaut exclude tsconfig exclude , donc cela rend également _impossible_ de remplacer la tsconfig défaut de tsconfig , même si tsconfig _ lui-même_ vous le permet cette.

Je ne sais pas pourquoi je parle ici comme un record battu répétant les _ définitions existantes_ et les utilisations existantes_ dans l' ensemble de l'écosystème _.

@ agilgur5

Et comme je l'ai dit plusieurs fois, ce qui en fait une concaténation très peu intuitive au lieu de remplacer
rend certains cas d'utilisation impossibles. Voici l'utilisation de TSDX:
https://github.com/jaredpalmer/tsdx/blob/17ffcd215f78a4e9d6936644cbeab332f6439088/src/createRollupConfig.ts#L149 -L178

Cette configuration peut être perturbée facilement, et je ne comprends pas pourquoi ce n'est pas évident pour vous. Je ne veux pas que ma bibliothèque soit fragile, et c'est pourquoi j'ai créé ce numéro.

le plus drôle, c'est que @ezolenko et moi avons déjà proposé une solution qui aidera à protéger, notamment TSDX, mais vous résistez toujours.

Les valeurs par défaut ne sont appliquées que si vous n'avez pas défini le nom de la propriété

Je suis d'accord avec le comportement

impossible pour eux de remplacer la valeur par défaut

La question est: pourquoi l'utilisateur devrait-il avoir accès à ce que l'auteur de la bibliothèque a interdit?

Nous devons avoir une configuration tsconfig qui ne peut pas être écrasée, mais en même temps, nous devons donner la possibilité d' étendre nos préréglages. Et c'est le point principal.

La solution réside uniquement dans la conception de la nouvelle API.

Cette configuration peut être perturbée facilement, et je ne comprends pas pourquoi ce n'est pas évident pour vous. Je ne veux pas que ma bibliothèque soit fragile, et c'est pourquoi j'ai créé ce numéro.

Vous retirez de ma bouche des mots que je n'ai pas prononcés à distance. Je n'ai pas dit qu'il ne pouvait pas et je n'ai pas dit non plus qu'il n'était pas fragile. Je viens de dire que _votre_ solution ne correspond à aucune _définition_existante_ ni _utilisation_existante_ dans _l'ensemble de l'écosystème_ des valeurs par défaut, ni aux documents eux-mêmes. Briser toute la définition de la valeur par défaut est clairement un comportement erroné.
Comme je l'ai dit à plusieurs reprises, ma suggestion était de fusionner les tableaux peu profonds à la place, c'est- tsconfig dire que tsconfigDefaults comme il le fait pour chaque propriété non-tableau et comme tsconfig _itself_ fonctionne .
Comme je l'ai dit à plusieurs reprises, cela peut être fait avec un changement de rupture ou un changement sans rupture.

S'il vous plaît, ne retirez pas les mots de ma bouche. Je me suis répété de nombreuses fois, veuillez lire les choses que j'ai écrites au lieu d'inventer des choses.

La question est: pourquoi l'utilisateur devrait-il avoir accès à ce que l'auteur de la bibliothèque a interdit?

tsconfig ne l'a pas interdit, TSDX ne l'a pas interdit, et rollup-plugin-typescript2 ne l'a pas non plus interdit, donc je ne sais pas de quoi vous parlez.

Nous devons avoir une configuration tsconfig qui ne peut pas être écrasée, mais en même temps, nous devons donner la possibilité d' étendre nos préréglages. Et c'est le point principal.

La solution réside uniquement dans la conception de la nouvelle API.

Oui, vous pouvez ajouter une option tsconfigConcat pour cela, et ce serait une "nouvelle API". Rompre l'API actuelle en réinventant toute la définition de la valeur par défaut crée tout un ensemble de nouveaux problèmes et de nouveaux comportements peu intuitifs. Sauf si une fusion profonde peut ne pas être intuitive pour les tableaux, il s'agit toujours d'un comportement _correct_. Une concaténation est tout simplement un comportement erroné, car ce n'est pas ce que signifie la valeur par défaut.

Un tsconfigConcat résoudrait votre cas d'utilisation et est plus intuitif car il a littéralement concat dans le nom et c'est exactement ce qu'il fait.
Changer tsconfigDefaults pour signifier "concaténation" n'est pas parce que, pour la cinquième fois, _pas ce que signifie par défaut_.

default = \ = concaténation. Ce n'est pas mon avis, c'est la définition.

@ agilgur5 désolé, mais vous ne pouvez pas être pris au sérieux.
chaque phrase est controversée, j'en ai assez.

Je soutiens simplement que l'API actuelle ne permet aucun travail adéquat avec elle, et c'est la raison pour laquelle elle est modifiée.
Je ne vais plus continuer ça.

Eh bien, je n'ai pas pris les mots de la bouche des gens, pas lu leurs mots réels, inventé les choses, attaqué le personnage d'un contributeur, fourni 0 lien, donné 0 alternative et ne considérer qu'une seule option et aucune autre, c'était vous .

Si vous souhaitez attaquer un contributeur qui essaie simplement d'être utile et qui donne de vraies définitions, de vrais cas d'utilisation et de vraies alternatives, je suppose que c'est votre perogatif: hausser les épaules:

Je pense que j'avais l'impression que la fusion lodash fusionnerait en fait des tableaux (les entrelacerait ou quelque chose du genre) lorsque j'écrivais cette partie. Ou je ne faisais même pas attention à ce qui arrive aux tableaux. Puisqu'il écrase apparemment le contenu des tableaux en utilisant des index comme noms d'élément (n'est-ce pas? Est-ce que ce truc javascript à propos des tableaux n'est pas à l'origine de vrais tableaux, mais plutôt des dictionnaires qui avaient des nombres pour les clés?), Notre documentation pour le moment ment.

Idéalement, les options tsconfigs default / main / override devraient permettre la personnalisation de tous les paramètres, à la fois les valeurs scalaires et les tableaux, de la même manière sans surprise. La manière Lodash de remplacer les éléments de tableau en fonction de l'index a un inconvénient majeur - vous ne pouvez pas créer de tableaux clairsemés littéraux (peut-être un tableau de remplissage avec un groupe de undefined s?). Cela signifie que la configuration de rollup doit être construite dynamiquement, et tsconfig, étant un fichier json, ne peut pas du tout les faire.

Même avec des tableaux clairsemés littéraux, le remplacement d'éléments basés sur l'index est bien trop fragile.

D'un autre côté, la concaténation est surprenante, si rien d'autre ne se comporte généralement de cette façon. Et seul ne permet pas la suppression des valeurs précédentes.

Basculer entre la concaténation et le remplacement comme je l'ai proposé à l'origine est doublement surprenant.

Changer les deux fusions pour remplacer les tableaux en gros comme le propose @ agilgur5 est probablement une option la moins surprenante, elle permettra de supprimer des valeurs, au prix de devoir répéter les valeurs que l'on souhaite conserver. C'est toujours un changement radical et les gens devront réécrire leurs configurations pour cela (voir https://xkcd.com/1172/).

Nous pouvons soit modifier le comportement de ces options, soit créer un nouvel ensemble et désapprouver les options existantes avec un avertissement.

(désolé si j'ai raté un point important quelque part, je n'ai lésiné que sur tout le fil)

@ezolenko je vois la prochaine façon

Regardons la situation et la motivation:
Le développeur souhaite ajouter certaines configurations nécessaires pour le typographie via le plugin de rollup.
Dans ce cas, nous ne devons pas empêcher le développeur d'ajouter des paramètres en toute sécurité, et ne pas perdre d'autres paramètres lors de la fusion de la configuration et des configurations de cumul.

Qu'est-ce que cela nous dit? Commençons par la sémantique:

Comme je le disais avant

Je suis d'accord avec le comportement par défaut. Il est logique d'appliquer la configuration par défaut uniquement lorsque tsconfig n'a pas de propriétés correspondantes ...

Nous pouvons repenser complètement cette chose.

Mes suggestions sont:

1. Appliquez les propriétés tsconfigDefaults lorsque l'original tsconfig n'a pas de propriétés correspondantes.
2. tsconfigOverride devrait s'en occuper.
   2.1 Cela devrait fonctionner comme avant avec des valeurs scalaires.
   2.2 Il doit concaténer les propriétés des tableaux. (probablement cela ne devrait rien casser et doit répondre à la motivation de configuration)

J'essaie simplement d'éviter la troisième option rpt2 supplémentaire, car elle compliquera cette API d'au moins 50% et tout développeur cessera de comprendre cela.

@ agilgur5 C'est merveilleux que la réalité et les mots que vous dites ne soient pas la même chose.

De plus, grâce à la notification par e-mail, j'ai lu le message original, et non édité 8 fois, pour paraître meilleur aux yeux des gens.
Personne ne voulait vous attaquer, d'ailleurs personne ne l'a fait.
On vous a simplement demandé d'arrêter d'être agressif et de cesser d'écrire des discours contradictoires dans ce fil.

• 0 liens - J'ai passé beaucoup de temps à comprendre le problème, à le décrire en détail, à donner des exemples et même des captures d'écran. Et aussi, j'ai même étudié votre TSDX, et vous ai dit que votre configuration est fragile, car je l'ai vérifiée. Et surtout, je ne suis pas resté silencieux, mais j'ai créé ce problème pour aggraver le problème pour ceux qui sont confrontés à cela.
• 0 alternatives - veuillez lire attentivement. J'ai commencé à proposer des solutions dès le premier message.
• enlever les mots - calmez-vous et arrêtez d'être narcissique au moins dans ce fil, c'est désagréable pour moi de travailler comme ça.

@maktarsis comment, dans votre approche, dev pourrait-il supprimer des entrées d'inclusion ou d'exclusion de tsconfig? Le scénario est le suivant: vous avez un tsconfig.json qui est utilisé ailleurs, vous voulez l'utiliser dans le rollup sans toucher json lui-même, mais vous voulez supprimer une ligne du tableau d'exclusion pour une raison quelconque.

@ezolenko J'ai compris votre avis.

Naturellement, comme indiqué ci-dessus, cela ne sera pas possible.
Mais nous parlons de possibilités plutôt que de motivation.

Je ne vois toujours pas de situations où nous devons réécrire l'exclusion.
Néanmoins, je suis d'avis que nous n'avons pas besoin d'écraser "exclure" du développeur. En d'autres termes, je ne peux pas imaginer pourquoi.
Il est nécessaire de comprendre la raison de «pour une raison quelconque».

Si vous souhaitez avoir cette possibilité dans tous les cas, vous devez fournir une API supplémentaire pour la concaténation.
Mais comme vous l'aurez compris, je pense que cela pourrait être non réclamé et simplement inutile.
L'exclusion de quelque chose de "exclure" peut ne pas être du tout nécessaire, mais si nous allons dans l'autre sens, alors nous compliquons la compréhension de la configuration.

Nous avons besoin des deux, ajouter quelque chose au tableau qui n'est pas là et en retirer quelque chose. Avec la fusion superficielle, l'ajout et la suppression sont effectués en répliquant l'ensemble du tableau (avec les modifications) à un niveau supérieur. Pas très pratique, mais utilisable.

C'est également le cas avec "esModuleInterop": true qui a empêché ma bibliothèque de fonctionner sur certains environnements.

Option de compilation inutile dans config.json:

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

Option de compilateur utile dans rollup-config:

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

La première suggestion de

Appliquez les propriétés tsconfigDefaults lorsque le tsconfig d'origine n'a pas de propriétés correspondantes.

^ le commentaire ci-dessus ne semble pas lié car ce n'est pas pour include ou les tableaux. La "suggestion" mentionnée est ce que tsconfigDefaults déjà.
De plus, moi et TSDX, utilisons beaucoup esModuleInterop donc je sais que cela fonctionne dans tsconfig.json , je ne sais pas ce que ce commentaire était censé signifier. La configuration publiée est également manquante compilerOptions , cela devrait être:

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

Mais cela l'emporterait et fonctionnerait comme prévu.

Notant ici que la fusion superficielle a déjà été mentionnée à plusieurs reprises dans ce repo: # 86 (qui mentionne le comportement de fusion superficiel de TS comme je l'ai fait ici), https://github.com/ezolenko/rollup-plugin-typescript2/issues/72 #issuecomment -383242460 et https://github.com/ezolenko/rollup-plugin-typescript2/issues/208#issuecomment -594237841