Rollup-plugin-typescript2: Die standardmäßige tsconfig-Option "include" wird vom Index aus der ursprünglichen tsconfig.json überschrieben

Dies macht die Verwendung von include unmöglich, da Sie nie wissen, wie lange das Array im tsconfig.json

Interessante Sache,
Wenn ich die Option typescript2 config include von tsconfigDefaults auf tsconfigOverride
Die ursprüngliche Option tsconfig.json include nach Index überschrieben.

das heißt, es ist genau das Gegenteil
aber es ist auch sehr schlecht

und noch etwas
nach einigen zusätzlichen Untersuchungen
Ich erkannte, dass das gleiche Verhalten auch für andere Array-Eigenschaften relevant ist

Ich habe dieses Problem bereits in https://github.com/jaredpalmer/tsdx/pull/666#discussion_r404847759 angesprochen , und gemäß dieser Ausgabe funktioniert die tiefe Zusammenführung von _.merge genau so. Es ist eine tiefe Zusammenführung, also werden die Arrays zusammengeführt und der Index ist die einzige Kennung des Arrays. Es mag unerwartet sein, aber es ist eine tiefe Verschmelzung, so funktionieren tiefe Verschmelzungen.

Tatsächlich werden diese Eigenschaften nicht verkettet, sondern die Werte in der Indexzelle ersetzt .

• Stattdessen würde ein Append / Concat überhaupt nicht zusammengeführt und würde keine Möglichkeit bieten, mit tsconfig überhaupt zu überschreiben. Das scheint mir das falsche Verhalten zu sein.
• Stattdessen würde eine flache Zusammenführung nur die Standardeinstellungen überschreiben. Ich bin mir nicht sicher, ob dies auch das erwartete Verhalten ist, aber es ähnelt der Funktionsweise von tsconfig in Bezug auf exclude : Wenn Sie eine hinzufügen exclude überschreibt die Standardeinstellungen.

Ich könnte eine PR schreiben, um eine flache Zusammenführung von nur include und exclude durchzuführen, aber das wäre ein hübscher Bruch einer Änderung; Ich habe keine Ahnung, wie sich das auf alle nachgeschalteten Benutzer auswirken könnte. Idk, wenn TSDX-Benutzer eine flache oder tiefe Zusammenführung erwarten, aber dies würde ihre Nutzung unterbrechen, wenn sie eine tiefe Zusammenführung erwarten.

Wenn ich die Option typescript2 config include von tsconfigDefaults auf tsconfigOverride
Die ursprüngliche Option tsconfig.json include nach Index überschrieben.

das heißt, es ist genau das Gegenteil

Ja, so soll tsconfigOverride funktionieren, es ist eine Überschreibung.

Ich erkannte, dass das gleiche Verhalten auch für andere Array-Eigenschaften relevant ist

Ja, auf diese Weise führt _.merge eine tiefe Verschmelzung durch, sodass alles in tsconfig , das ein Array ist, dieselbe Änderung aufweist.

@ agilgur5 danke für die Antwort!

1) Aus meiner Sicht macht dieses Verhalten die Konfiguration völlig nutzlos. Wir können die Zuverlässigkeit der Konfiguration nicht garantieren, wenn wir an eine Position im Array gebunden sind.

2) In der Tat wäre es eine bahnbrechende Veränderung. Aber wenn unsere Richtung darin besteht, den besten DX zu erzielen, sollten wir diese Sache klar und nützlich machen.

Ich habe einen Trick in der Tasche, um mit dieser Sache umzugehen, aber aus der Perspektive des sauberen Codes sieht es laut aus - lesen Sie einfach tsconfig , holen Sie sich die Eigenschaft include und verketten Sie diese mit meinem Array. Es sieht so aus, als ob es einfacher sein sollte.

Mein Vorschlag:
1) für Standard - Sammeln Sie die Standardeigenschaft und verketten Sie sie mit der ursprünglichen tsconfig. Duplikate entfernen.
2) für Override - nur Override-Option anwenden

Standardeinstellungen werden normalerweise nicht verkettet, wenn sie überschrieben werden. Sie werden überschrieben. Und wie ich oben erwähnt habe, macht es die Verkettung unmöglich, den Standardwert mit einem tsconfig zu überschreiben. Das klingt für mich in mehrfacher Hinsicht nach falschem Verhalten, daher rate ich dringend davon ab.

Ich denke, alle Optionen sind verwirrend. Ich bin mir nicht sicher, ob ich damit einverstanden bin, dass eine davon die "beste DX" ist. Eine flache Zusammenführung kommt der Funktionsweise von tsconfig mit der Standardeinstellung exclude am nächsten, aber dies ist nicht ohne Kompromisse möglich.
Um Veränderungen zu brechen, muss im Allgemeinen viel nachgedacht werden, weshalb ich das angesprochen habe - die nachgelagerten Effekte sind nicht trivial; TSDX müsste auch eine wichtige Änderung veröffentlichen, um auf eine solche Änderung zu aktualisieren.

@ agilgur5 gut, dann kann ich weder Standard noch Override verwenden.
Ursache? Es gibt keine Garantie dafür, dass kein Wert in diesen Index geschrieben wird.
Außerdem können Sie alles über undefiniert als Wert des Arrays umgehen und Ihren benötigten Wert weiter hinzufügen. Und es stellt sich heraus, dass es eine Lücke in diesem System gibt? Einfach toll.

Der Fall:

1. Ich möchte meine zusätzlichen d.ts -Tippings in der Eigenschaft "include" config hinzufügen.
2. Der Benutzer fügt sein Verzeichnis src in "include" ein, wobei ein anderes Projekt spezifische d.ts -Tipps außerhalb von src .

1. ['config.d.ts`]
   2. ['src', 'some.d.ts', 'another.d.ts']
2. Ergebnis: ['src', 'some.d.ts', 'another.d.ts']

Wie Sie sehen, gibt es keine Möglichkeit, dies richtig zu konfigurieren. Ich sollte tsconfig.json lesen, die Eigenschaft "include" abrufen und diese in ['src', 'some.d.ts', 'another.d.ts', 'config.d.ts'] zusammenführen.
Und ich denke, das ist ein kompletter Aufwand.

In der Zwischenzeit habe ich herausgefunden, wo das Problem liegt. Andere finden es möglicherweise nicht heraus und verbringen ihre kostbare Zeit damit, herauszufinden, was für sie nicht funktioniert.
Und nach Ihrer ersten Nachricht habe ich bereits mindestens zwei verwandte Probleme gesehen. Und es wird weiter und weiter gehen.

Ich sehe es so, dass wenn wir alles so lassen, wie es ist, ich es nicht benutzen kann, es eine Black Box für mich ist, weil ich nichts garantieren kann.
Es gibt keinen Raum für persönliche Vorlieben "wie" / "nicht mögen".
Dies kann entweder verwendet werden oder nicht. Und das kann es nicht.

Ich habe kein Problem damit, die Meinungen anderer zu sammeln, die daran beteiligt sind.
Und noch etwas: Ich habe keine Probleme, bei der aktuellen Lösung zu bleiben. Ich habe den oben beschriebenen Hack, bei dem ich bereit bin, mich zu halten. Aber ich verstehe nicht, was das Problem ist, diese Lösung transparent zu machen, ohne an die Tatsache gebunden zu sein, dass sie bahnbrechende Änderungen mit sich bringt.

Ich meine, Sie geben hier Ihre eigene Präferenz an, während ich bereits mehrere verschiedene Optionen angegeben habe. Ich habe bereits zweimal gesagt, warum diese Präferenz, die Verkettung, grundlegend gebrochen, ähnlich unintuitiv und überhaupt nicht "transparent" ist. Um es zu wiederholen: Verkettung ist keine bahnbrechende Änderung, sondern macht das Überschreiben von Dingen buchstäblich unmöglich . Ich werde es noch einmal wiederholen, unmöglich .
Es ist unmöglich , mit Verkettung außer Kraft zu setzen ist keine „Präferenz“, das ist eine Tatsache.

Auch hier ist ein "Standard", der nicht überschrieben werden kann, kein Standard, das ist eine Voraussetzung. Das Ändern einer "Standardeinstellung" in eine Anforderung ist nicht sinnvoll und ein falsches Verhalten.

Sie können die Tiefenzusammenführung jetzt überschreiben, Sie können eine Verkettung nicht überschreiben. Es macht keinen Sinn, einen bestehenden Anwendungsfall unmöglich zu machen.

Ich habe auch schon zweimal eine alternative Option angegeben, die nicht grundlegend gebrochen ist, was eine flache Zusammenführung ist. Ich werde es noch einmal wiederholen. Sie können auch eine flache Zusammenführung verwenden, um dies zu lösen.
Ob das besser ist, ist umstritten. Es gibt Kompromisse zu allem.

Ich habe hier bereits dazu beigetragen, Fehler zu beheben (ich weiß, dass es _.merge weil ich die Codebasis gelesen habe), und eine Bibliothek, die ich pflege, macht einen erheblichen Teil der Nutzung dieser Bibliothek aus (~ 10%) hier nicht nur reden ...

Ganz zu schweigen davon, dass dies behoben werden kann, ohne dass Änderungen vorgenommen werden. Sie können eine neue Option für tsconfigConcat oder tsconfigDefaultShallow usw. hinzufügen.

Zu sagen, dass es nur eine Option gibt und diese brechen muss und einen bestehenden Anwendungsfall unmöglich machen muss, ist einfach nicht wahr.

Ich denke, wir müssen die Dinge kaputt machen, egal was wir hier machen. Damit es sich gemäß dem Geist der Dokumentation und der Eigenschaftsnamen verhält, sollte es grundsätzlich Folgendes tun:

• tsconfigDefaults - Dies ist das Objekt, in das alles unten tief verschmolzen wird
• tsconfig - Dies ist das Objekt, das wir vom Typoskript erhalten, nach seinen eigenen Importen und allem. Alle Werte hier ersetzen Werte in tsconfigDefaults . Alle Arrays hier sind mit Arrays in tsconfigDefaults verkettet .
• tsconfigOverride - dies ist die nukleare Option. Objekte werden immer noch tief zusammengeführt, aber Arrays ersetzen hier Arrays im Großhandel. Wenn Sie hier also ein leeres Include-Array angeben, enthält final tsconfig überhaupt keine Includes.

Deckt das alle Fälle ab, die wir unterstützen möchten (nachdem Benutzer entsprechende Änderungen vorgenommen haben), oder fehlt mir etwas?

@ezolenko klingt erstaunlich und macht sehr viel Sinn zu verwenden

@ezolenko Ich bin nicht sicher, warum Sie Dinge brechen müssen? Ich habe Optionen angegeben, die bereits nicht brechen.

Ich bin nicht sicher, wie das, was Sie aufgelistet haben, "den Geist der Dokumentation und der Eigenschaftsnamen" widerspiegelt, weil die Dokumente sagen:

Das Objekt übergeben als tsconfigDefaults wird mit geladen zusammengeführt werden tsconfig.json . Die endgültige Konfiguration, die an Typoskript übergeben wird, ist das Ergebnis von Werten in tsconfigDefaults die durch Werte in geladenen tsconfig.json
[...]
Dies ist eine tiefgreifende Zusammenführung (Objekte werden zusammengeführt , Arrays werden verkettet, Grundelemente werden ersetzt usw.), erhöhen Sie verbosity auf 3 und suchen Sie nach parsed tsconfig wenn Sie etwas Unerwartetes erhalten.

Es heißt "zusammengeführt", "ersetzt" und "tief zusammengeführt", was alles bedeutet, dass die Standardeinstellung ersetzt und überschrieben wird. Es gibt einen einzigen Verweis auf "verkettet", der sich vom Rest unterscheidet, aber eine tiefe Zusammenführung verkettet tatsächlich nicht. 5 Referenzen sagen eins und eine sechste ist falsch. Für mich klingt das so, als ob die 6. Referenz, die falsch ist, korrigiert werden sollte, nicht die 5 richtigen, die in die falsche 6 geändert wurden.

lodash ist der De-facto-Standard und seine Definition der Zusammenführung ist nicht zu verketten. Die Definition von Standardwerten ist, dass sie überschrieben werden, wenn Sie denselben Eigenschaftswert festlegen, _not_ verkettet:

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

Wenn Sie eine Verkettungsoption hinzufügen möchten, sollte dies meiner Meinung nach eine separate Konfiguration sein, da sie auch nicht mit mehr als 5 Referenzen in den Dokumenten übereinstimmt und weil dies einfach nicht die Standardeinstellungen bedeutet, weder in der Definition noch in der Verwendung in irgendeiner Bibliothek.

Es bricht auch die Symmetrie mit tsconfigOverride sowie seinen eigenen Dokumenten:

• tsconfigOverride : {}
  Siehe tsconfigDefaults .

Ich erwarte, dass die Standardeinstellungen überschrieben werden, das ist die Definition. Stattdessen ist es unglaublich unintuitiv, sie zu verketten. Eine tiefe Zusammenführung mag für Arrays nicht intuitiv sein, aber die Dokumente sagen eindeutig, dass es sich um eine tiefe Zusammenführung handelt, und ich habe schnell verstanden, dass dies das Problem war, da Indizes relevant waren. Ich habe auch keinen Fehler gemeldet, da dies in den Dokumenten angegeben und sogar mit Deep Merge verknüpft ist - das ist beabsichtigtes Verhalten, kein Fehler.

Wie ich bereits sagte, kann das flache Zusammenführen der Arrays intuitiver sein, da tsconfig _itself_ auf diese Weise tatsächlich funktioniert. Wie ich oben verlinkt habe, verkettet sich tsconfig _itself_ nicht, wenn Sie exclude hinzufügen, sondern überschreibt die vorhandenen exclude .

Die Verkettung entspricht also nicht bereits mehr als 5 Referenzen in den Dokumenten, der Definition der Zusammenführung, der Definition der Standardeinstellungen oder dem eigenen Verhalten von tsconfig . Und es bricht Symmetrie und Dokumente anderer Optionen. Ich bin mir nicht sicher, wie das intuitiv ist.

Und wie ich schon mehrfach gesagt habe, macht es eine sehr unintuitive Verkettung, anstatt sie zu überschreiben, bestimmte Anwendungsfälle unmöglich . Hier ist die Verwendung von TSDX:

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

Wenn Sie Ihre eigenen exclude hinzufügen, werden die von uns festgelegten Standardeinstellungen überschrieben. Die Standardeinstellungen werden nur angewendet, wenn Sie den Eigenschaftsnamen nicht wie jeden anderen Eigenschaftsnamen festgelegt haben (dies ist wiederum die Definition der Standardeinstellungen und die Funktionsweise der Standardeinstellungen in allen Bibliotheken).

Wenn Sie dies ändern, um es zu verketten, hat der Benutzer jetzt keine Möglichkeit, unsere Standardeinstellung exclude zu überschreiben. Es ist für ihn unmöglich , die Standardeinstellung zu überschreiben. Wir versenden auch tsconfig 's Standard exclude Dies macht es auch unmöglich , den tsconfig zu überschreiben, obwohl tsconfig _itself_ dies zulässt Das.

Ich bin mir nicht sicher, warum ich hier wie ein gebrochener Rekord spreche, indem ich vorhandene Definitionen und vorhandene Verwendung im gesamten Ökosystem wiederhole.

@ agilgur5

Und wie ich bereits mehrfach gesagt habe, ist dies eine sehr unintuitive Verkettung, anstatt sie zu überschreiben
macht bestimmte Anwendungsfälle unmöglich. Hier ist die Verwendung von TSDX:
https://github.com/jaredpalmer/tsdx/blob/17ffcd215f78a4e9d6936644cbeab332f6439088/src/createRollupConfig.ts#L149 -L178

Diese Konfiguration kann leicht gestört werden, und ich verstehe nicht, warum dies für Sie nicht offensichtlich ist. Ich möchte nicht, dass meine Bibliothek zerbrechlich ist, und deshalb habe ich dieses Problem erstellt.

Das Lustige ist, dass @ezolenko und ich bereits eine Lösung vorgeschlagen haben, die zum Schutz beiträgt, einschließlich TSDX, aber Sie widersetzen sich trotzdem.

Die Standardeinstellungen werden nur angewendet, wenn Sie den Eigenschaftsnamen nicht festgelegt haben

Ich stimme dem Standardverhalten zu. Es ist sinnvoll, config default nur anzuwenden, wenn tsconfig keine entsprechenden Eigenschaften hat. Dies führt jedoch zu vielen anderen, komplexeren Problemen, deren Lösung die API überkomplizieren wird.

Es ist ihnen unmöglich, die Standardeinstellung zu überschreiben

Die Frage ist, warum der Benutzer Zugriff auf das haben sollte, was der Autor der Bibliothek verboten hat.

Wir müssen eine tsconfig-Konfiguration nutzen, die nicht überschrieben werden kann, aber gleichzeitig müssen wir die Möglichkeit geben , unsere Voreinstellungen zu

Die Lösung liegt nur im Design der neuen API.

Diese Konfiguration kann leicht gestört werden, und ich verstehe nicht, warum dies für Sie nicht offensichtlich ist. Ich möchte nicht, dass meine Bibliothek zerbrechlich ist, und deshalb habe ich dieses Problem erstellt.

Du nimmst mir Worte aus dem Mund, die ich nicht aus der Ferne gesagt habe. Ich habe nicht gesagt, dass es nicht kann und ich habe auch nicht gesagt, dass es nicht zerbrechlich ist. Ich habe nur gesagt, dass Ihre Lösung weder einer vorhandenen Definition noch einer vorhandenen Verwendung im gesamten Ökosystem der
Wie ich bereits mehrfach gesagt habe, war mein Vorschlag, stattdessen Arrays flach zusammenzuführen, dh tsconfig überschreibt tsconfigDefaults wie dies für jede Nicht-Array-Eigenschaft der Fall ist und tsconfig _itself_ funktioniert .
Wie ich schon mehrmals gesagt habe, kann dies mit einer bahnbrechenden Änderung oder einer nicht brechenden Änderung erfolgen.

Bitte nimm keine Worte aus meinem Mund. Ich habe mich viele Male wiederholt, bitte lesen Sie die tatsächlichen Dinge, die ich geschrieben habe, anstatt Dinge zu erfinden.

Die Frage ist, warum der Benutzer Zugriff auf das haben sollte, was der Autor der Bibliothek verboten hat.

tsconfig hat das nicht verboten, TSDX hat das nicht verboten, und rollup-plugin-typescript2 hat das auch nicht verboten, also weiß ich nicht, worauf Sie sich beziehen.

Wir müssen eine tsconfig-Konfiguration nutzen, die nicht überschrieben werden kann, aber gleichzeitig müssen wir die Möglichkeit geben , unsere Voreinstellungen zu

Die Lösung liegt nur im Design der neuen API.

Ja, Sie können hierfür eine tsconfigConcat -Option hinzufügen, und das wäre eine "neue API". Das Aufbrechen der aktuellen API durch Neuerfindung der gesamten Standarddefinition führt zu einer Reihe neuer Probleme und neuem, nicht intuitivem Verhalten. Außer wenn eine tiefe Zusammenführung für Arrays nicht intuitiv ist, handelt es sich dennoch um ein korrektes Verhalten. Eine Verkettung ist einfach ein falsches Verhalten, da dies nicht die Standardeinstellung ist.

Ein tsconfigConcat würde Ihren Anwendungsfall lösen und ist intuitiver, da der Name buchstäblich concat enthält und genau das ist, was er tut.
Das Ändern von tsconfigDefaults in "Verkettung" bedeutet nicht, dass dies zum fünften Mal _nicht das ist, was Standard bedeutet_.

Standard = \ = Verkettung. Das ist nicht meine Meinung, das ist die Definition.

@ agilgur5 sorry, aber du kannst nicht ernst genommen werden.
Jeder deiner Sätze ist umstritten, ich bin es leid.

Ich behaupte einfach, dass die aktuelle API überhaupt keine angemessene Arbeit damit erlaubt, und dies ist der Grund für die Änderung.
Ich werde das nicht mehr fortsetzen.

Nun, ich habe den Leuten keine Wörter aus dem Mund genommen, ihre tatsächlichen Wörter nicht gelesen, Dinge erfunden, den Charakter eines Mitwirkenden angegriffen, 0 Links bereitgestellt, 0 Alternativen angegeben und nur eine einzige Option in Betracht gezogen und keine anderen, das waren Sie .

Wenn Sie einen Mitwirkenden angreifen möchten, der nur versucht, hilfreich zu sein und echte Definitionen, echte Anwendungsfälle und echte Alternativen enthält, ist dies wahrscheinlich Ihr Recht: Achselzucken:

Ich glaube, ich hatte den Eindruck, dass Lodash Merge tatsächlich Arrays zusammenführen würde (verschachteln oder so), als ich diesen Teil schrieb. Oder ich habe nicht einmal darauf geachtet, was mit Arrays passiert. Da der Inhalt von Arrays anscheinend mit Indizes als Elementnamen überschrieben wird (richtig? Handelt es sich bei diesem Javascript darum, dass Arrays ursprünglich keine echten Arrays sind, sondern Wörterbücher, die zufällig Zahlen für Schlüssel enthalten?), Liegt derzeit unsere Dokumentation.

Im Idealfall sollten die Standardoptionen / main / override tsconfigs die Anpassung aller Parameter, sowohl der Skalarwerte als auch der Arrays, auf dieselbe nicht überraschende Weise ermöglichen. Die Lodash-Methode zum Ersetzen von Array-Elementen basierend auf dem Index hat einen großen Nachteil: Sie können keine wörtlich spärlichen Arrays erstellen (möglicherweise das Auffüllen eines Arrays mit einer Reihe von undefined s?). Das bedeutet, dass die Rollup-Konfiguration dynamisch erstellt werden muss und tsconfig als JSON-Datei diese überhaupt nicht ausführen kann.

Selbst bei buchstäblich spärlichen Arrays ist das Ersetzen von Elementen basierend auf dem Index viel zu fragil.

Auf der anderen Seite ist die Verkettung überraschend, wenn sich normalerweise nichts anderes so verhält. Und allein erlaubt nicht das Entfernen vorheriger Werte.

Das Umschalten zwischen Verketten und Ersetzen, wie ich es ursprünglich vorgeschlagen hatte, ist doppelt überraschend.

Das Ändern beider Zusammenführungen, um Arrays im Großhandel zu ersetzen, wie von @ agilgur5 vorgeschlagen, ist wahrscheinlich die am wenigsten überraschende Option. Sie ermöglicht das Entfernen von Werten auf Kosten der Wiederholung von Werten, die beibehalten werden sollen. Es ist jedoch immer noch eine bahnbrechende Änderung, und die Leute müssen ihre Konfigurationen dafür neu schreiben (siehe https://xkcd.com/1172/).

Wir können entweder das Verhalten dieser Optionen ändern oder einen neuen Satz erstellen und vorhandene Optionen mit einer Warnung verwerfen.

(Entschuldigung, wenn ich irgendwo einen wichtigen Punkt verpasst habe, habe ich nur den ganzen Thread gekürzt)

@ezolenko Ich sehe den nächsten Weg

Schauen wir uns die Situation und die Motivation an:
Der Entwickler möchte einige notwendige Konfigurationen für Typoskript über das Rollup-Plugin hinzufügen.
In diesem Fall sollten wir den Entwickler nicht daran hindern, Einstellungen sicher hinzuzufügen, und keine anderen Einstellungen verlieren, wenn die Konfigurations- und Rollup-Konfigurationen zusammengeführt werden.

Was sagt uns das? Beginnen wir mit der Semantik:

Wie ich bereits gesagt habe

Ich stimme dem Standardverhalten zu. Es ist sinnvoll, config default nur anzuwenden, wenn tsconfig keine entsprechenden Eigenschaften hat ...

Wir können dieses Ding komplett neu gestalten.

Meine Vorschläge sind:

1. Wenden Sie tsconfigDefaults -Eigenschaften an, wenn die ursprünglichen tsconfig keine entsprechenden Eigenschaften haben.
2. tsconfigOverride sollte sich darum kümmern.
   2.1 Es sollte wie bisher mit skalaren Werten funktionieren.
   2.2 Es sollte Array-Eigenschaften verketten. (Wahrscheinlich sollte dies nichts kaputt machen und muss der Konfigurationsmotivation entsprechen.)

Ich versuche nur, die dritte zusätzliche Option rpt2 zu vermeiden, da dies diese API um mindestens 50% kompliziert und jeder Entwickler dies nicht mehr versteht.

@ agilgur5 Es ist wunderbar, dass die Realität und die Worte, die du sagst, nicht dasselbe sind.

Dank der E-Mail-Benachrichtigung habe ich auch die ursprüngliche Nachricht gelesen und nicht achtmal bearbeitet, um in den Augen der Menschen besser zu wirken.
Niemand wollte dich angreifen, außerdem hat es niemand getan.
Sie wurden einfach gebeten, nicht mehr aggressiv zu sein und keine widersprüchlichen Reden mehr in diesem Thread zu schreiben.

• 0 Links - Ich habe viel Zeit damit verbracht, das Problem zu verstehen, es vollständig zu beschreiben, Beispiele und sogar Screenshots zu geben. Außerdem habe ich sogar Ihren TSDX studiert und Ihnen gesagt, dass Ihre Konfiguration fragil ist, weil ich sie überprüft habe. Und vor allem habe ich nicht geschwiegen, sondern dieses Problem erstellt, um das Problem für diejenigen zu eskalieren, die damit konfrontiert sind.
• 0 Alternativen - bitte sorgfältig lesen. Ich begann von der ersten Nachricht an, Lösungen anzubieten.
• Worte herausnehmen - beruhigen Sie sich und hören Sie zumindest in diesem Thread auf, narzisstisch zu sein. Es ist unangenehm für mich, so zu arbeiten.

@maktarsis Wie könnte dev in Ihrem Ansatz Einschluss- oder Ausschlusseinträge aus tsconfig entfernen? Das Szenario lautet: Sie haben eine tsconfig.json, die an anderer Stelle verwendet wird. Sie möchten sie im Rollup verwenden, ohne json selbst zu berühren, aber Sie möchten aus irgendeinem Grund eine Zeile aus dem Ausschluss-Array entfernen.

@ezolenko Ich habe deine aber verstanden.

Wie oben diskutiert, wird dies natürlich nicht möglich sein.
Wir sprechen aber eher von Möglichkeiten als von Motivation.

Ich sehe immer noch keine Situationen, in denen wir den Ausschluss neu schreiben müssen.
Trotzdem bin ich der Meinung, dass wir das "Ausschließen" von dev nicht überschreiben müssen. Mit anderen Worten, ich kann mir nicht vorstellen warum.
Es ist notwendig, den Grund für "aus irgendeinem Grund" zu verstehen.

Wenn Sie diese Möglichkeit auf jeden Fall haben möchten, müssen Sie eine zusätzliche API für die Verkettung bereitstellen.
Aber wie Sie vielleicht verstehen, denke ich, dass es nicht beansprucht und einfach unnötig sein könnte.
Der Ausschluss von etwas von "ausschließen" ist möglicherweise überhaupt nicht erforderlich, aber wenn wir in die andere Richtung gehen, erschweren wir das Verständnis der Konfiguration.

Wir brauchen beides, indem wir dem Array etwas hinzufügen, das nicht vorhanden ist, und etwas daraus entfernen. Bei der flachen Zusammenführung erfolgt das Hinzufügen und Entfernen durch Replizieren des gesamten Arrays (mit Änderungen) auf einer höheren Ebene. Nicht sehr praktisch, aber brauchbar.

Dies ist auch bei "esModuleInterop": true der Fall, wodurch meine Bibliothek in einigen Umgebungen nicht funktioniert.

Nutzlose Compileroption in config.json:

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

Nützliche Compileroption in der Rollup-Konfiguration:

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

@maktarsis erster Vorschlag war für mich das erwartete Verhalten:

Wenden Sie die Eigenschaften tsconfigDefaults an, wenn die ursprüngliche tsconfig keine entsprechenden Eigenschaften hat.

^ Der obige Kommentar scheint nichts damit zu tun zu haben, da er nicht für include oder Arrays gilt. Der erwähnte "Vorschlag" ist das, was tsconfigDefaults bereits tut.
Außerdem verwenden ich und TSDX esModuleInterop stark, sodass ich weiß, dass es in tsconfig.json funktioniert, nicht sicher, was dieser Kommentar bedeuten sollte. In der veröffentlichten Konfiguration fehlt auch compilerOptions , es sollte sein:

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

Aber das würde außer Kraft setzen und wie beabsichtigt funktionieren.

In diesem Repo wurde bereits einige Male darauf hingewiesen, dass die flache Zusammenführung bereits einige Male erwähnt wurde: # 86 (in dem das flache Zusammenführungsverhalten von TS wie hier erwähnt wird), https://github.com/ezolenko/rollup-plugin-typescript2/issues/72 #issuecomment -383242460 und https://github.com/ezolenko/rollup-plugin-typescript2/issues/208#issuecomment -594237841