Rollup-plugin-typescript2: デフォルトのtsconfigオプション「include」は、元のtsconfig.jsonのインデックスによって上書きされます

これにより、 tsconfig.json内の配列の長さがわからないため、 includeできなくなります。

面白いこと、
typescript2 config includeオプションをtsconfigDefaultsからtsconfigOverride
元のtsconfig.json includeオプションをインデックスで上書きします。

つまり、それは正反対です
でもそれもとても悪いです

後もう一つ
いくつかの追加調査の後
同じ動作が他の配列プロパティにも関連していることに気づきました

だから私は以前https://github.com/jaredpalmer/tsdx/pull/666#discussion_r404847759でこの問題にぶつかったことがあり、その問題ごとに、それが_.mergeのディープマージがどのように機能するかです。 これはディープマージであるため、配列をマージし、インデックスが配列の唯一の識別子です。 それは_予期しない_かもしれませんが、それは深いマージであり、それが深いマージがどのように機能するかです。

実際、これらのプロパティは連結されませんが、インデックスセルの値が置き換えられます。

• 代わりに、追加/連結を実行してもマージはまったく行われず、 tsconfigで上書きする方法はまったくありません。 それは私には間違った行動のように思えます。
• 代わりに、浅いマージを実行すると、デフォルトの動作が上書きされるだけで、予想される動作もわかりませんが、 excludeに関してtsconfigがどのように機能するかと似ています。 exclude 、デフォルトを上書きします。

includeとexcludeだけで浅いマージを行うPRを作成することもできますが、それは変更を_かなり_壊すことになります。 それがすべてのダウンストリームユーザーにどのように影響するかはわかりません。 TSDXユーザーが浅いまたは深いマージを期待している場合はIdkですが、深いものを期待している場合は使用法が損なわれます。

typescript2 config includeオプションをtsconfigDefaultsからtsconfigOverride
元のtsconfig.json includeオプションをインデックスで上書きします。

つまり、それは正反対です

はい、それはtsconfigOverrideが機能することになっている方法です、それはオーバーライドです。

同じ動作が他の配列プロパティにも関連していることに気づきました

はい、それが_.mergeがディープマージを行う方法です。したがって、配列であるtsconfig内のすべてのものに同じ変更があります。

@ agilgur5返信ありがとう

1）私の観点からは、この動作により構成はまったく役に立たなくなります。 アレイ内の位置に関連付けられている場合、構成の信頼性を保証することはできません。

2）確かに、それは壊滅的な変化になるでしょう。 しかし、私たちの方向性が最高のDXを達成することである場合、これを明確で有用なものにする必要があります。

私はこれを処理するためのトリックをポケットに入れていますが、クリーンなコードの観点からはノイズが多いように見えます- tsconfig読み取り、 includeプロパティを取得して、これを配列と連結します。 簡単なはずです。

私のおすすめ：
1）デフォルトの場合-デフォルトのプロパティを収集し、元のtsconfigと連結します。 重複を削除します。
2）オーバーライドの場合-オーバーライドオプションのみを適用します

デフォルトは通常、オーバーライドされたときに連結されず、オーバーライドされます。 そして、前述したように、連結により、デフォルトをtsconfigオーバーライドすることは_不可能_になります。 それは私にはさまざまな意味で間違った行動のように聞こえるので、私はそれを強くお勧めしません。

すべてのオプションが混乱していると思いますが、これらのいずれかが「最高のDX」であることに同意するかどうかはわかりません。 浅いマージは、 tsconfigがデフォルトのexcludeでどのように機能するかに最も近いものですが、トレードオフがなければ実現しません。
一般に、重大な変更には多くの考慮を払う必要があります。そのため、私はそれを取り上げました。下流の影響は重要です。 TSDXは、そのような変更に更新するために、重大な変更をリリースする必要もあります。

@ agilgur5は問題ありません。デフォルトを使用することも、オーバーライドすることもできません。
原因？ そのインデックスに値が書き込まれないという保証はありません。
さらに、配列の値としてundefinedを使用し、必要な値をさらに追加することで、すべてを回避できます。 そして、このシステムにはギャップがあることがわかりましたか？ ただ素晴らしい。

ケース：

1. 「include」configプロパティ内にd.tsタイプを追加したいと思います。
2. ユーザーは自分のsrcディレクトリを「include」内に置き、別のプロジェクト固有のd.tsタイプをsrc外に置きます。

1. ['config.d.ts`]
   2。['src'、 'some.d.ts'、 'another.d.ts']
2. 結果：['src'、 'some.d.ts'、 'another.d.ts']

ご覧のとおり、これを適切に構成する方法はありません。 tsconfig.jsonを読み、その「include」プロパティを取得して、これを['src'、 'some.d.ts'、 'another.d.ts'、 'config.d.ts']にマージする必要があります。
そして、これは完全なオーバーヘッドだと思います。

その間、私は問題が何であるかを理解しました。 他の人はそれを理解せず、彼らにとって何がうまくいかないかを理解するために彼らの貴重な時間を費やすかもしれません。
そして、あなたの最初のメッセージの後、私はすでに少なくとも2つの関連する問題を見てきました。 そして、それはどんどん続きます。

すべてをそのままにしておくと使えなくなる、何も保証できないのでブラックボックスだと思います。
「好き」/「嫌い」という個人的な好みの余地はありません。
これは使用することも使用しないこともできます。 そして、それはできません。

これに関わっている他の人の意見を集めるのに問題はありません。
そしてもう1つ、現在のソリューションを維持するのに問題はありません。上記のハックがあり、これを使用する準備ができています。 しかし、私は、このソリューションを透明にすることの問題が何であるかを理解していません。それは、重大な変更を伴うという事実に縛られることはありません。

つまり、私がすでに複数の異なるオプションを与えている間、あなたはここであなた自身の好みを与えているということです。 その好みである連結が根本的に壊れており、同様に直感的でなく、まったく「透明」ではない理由については、すでに2回述べました。 繰り返しになりますが、連結は単なる破壊的な変更ではなく、文字通りオーバーライドを不可能にします。 もう一度繰り返します、不可能です。
連結でオーバーライドできないことは「好み」ではありません。それは事実です。

繰り返しますが、オーバーライドできない「デフォルト」はデフォルトではなく、それが要件です。 「デフォルト」を要件に変更することは意味がなく、間違った動作です。

現在、ディープマージをオーバーライドできますが、連結をオーバーライドすることはできません。 既存のユースケースを不可能にすることは意味がありません。

私はまた、根本的に壊れていない代替オプションをすでに2回与えました。これは、浅いマージです。 もう一度繰り返しますが、浅いマージを使用してこれを解決することもできます。
それが良いかどうかは議論の余地があります。 すべてにトレードオフがあります。

私は以前にバグを修正するためにここに貢献しました（コードベースを読んだので_.mergeだと知っています）そして私が維持しているライブラリはこのライブラリの使用のかなりの部分を占めています（〜10％）、私はここで論点を述べるだけではありません...

言うまでもなく、これは変更を壊すことなく解決できます。 tsconfigConcatやtsconfigDefaultShallowなどの新しいオプションを追加できます。

選択肢は1つしかなく、それは壊れていて、既存のユースケースを不可能にしなければならないと言うのは、単純に真実ではありません。

ここで何をしても、物事を壊さなければならないと思います。 ドキュメントとプロパティ名の精神に従って動作させるには、基本的に次のようにする必要があります。

• tsconfigDefaults -これは、以下のすべてが深くマージされるオブジェクトです
• tsconfig -これは、独自のインポートとすべての後に、typescriptから取得するオブジェクトです。 ここでのすべての値は、 tsconfigDefaults値を置き換えます。 ここにあるすべての配列は、 tsconfigDefaults配列と連結されています。
• tsconfigOverride -これは核の選択肢です。 オブジェクトはまだ深くマージされていますが、ここの配列は大規模な配列に取って代わります。 したがって、ここで空のインクルード配列を指定すると、最終的なtsconfigにはインクルードがまったくありません。

それは私たちがサポートしたいすべてのケースをカバーしますか（ユーザーが適切な変更を加えた後）、または私は何かが足りませんか？

@ezolenkoは素晴らしいサウンドで、使用するのが理にかなっています

@ezolenkoなぜあなたが物事を壊さなければならないのか分かりませんか？ 私はすでに壊れていないオプションを与えました。

あなたがリストしたものが「ドキュメントの精神とプロパティ名」をどのように反映しているかはわかりません。ドキュメントには次のように書かれているからです。

tsconfigDefaultsとして渡されたオブジェクトは、ロードされたtsconfig.jsonとマージされます。 typescriptに渡される最終的な構成は、 tsconfigDefaults値が、ロードされたtsconfig.json値に置き換えられた結果になります。
[...]
これはディープマージ（オブジェクトのマージ、配列の連結、プリミティブの置換など）であり、 verbosityを3に増やし、予期しないことが発生した場合はparsed tsconfigを探します。

「マージ済み」、「置換済み」、「ディープマージ」と表示されます。これらはすべて、デフォルトを置換してオーバーライドすることを意味します。 「他の部分とは異なる」「連結」への単一の参照がありますが、深いマージは実際には連結しません。 5つの参照は1つのことを言い、6番目は正しくありません。 私には、間違っている6番目の参照を修正する必要があるように聞こえますが、5つの正しい参照を間違った6番目に変更する必要はありません。

lodashは事実上の標準であり、マージの定義は連結することではありません。 デフォルトの定義は、同じプロパティ値を_not_concatenatedに設定するとオーバーライドされるというものです。

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

連結オプションを追加したい場合は、別の構成にする必要があると思います。これは、ドキュメント内の5つ以上の参照とも一致せず、定義でも使用法でも、デフォルトの意味ではないためです。図書館。

また、 tsconfigOverrideと独自のドキュメントで対称性を破ります。

• tsconfigOverride ： {}
tsconfigDefaults参照してください。

デフォルトがオーバーライドされることを期待しています。つまり、デフォルトを連結することは、信じられないほど直感的ではありません。 ディープマージは配列にとって直感的ではないかもしれませんが、ドキュメントにはそれがディープマージであるとはっきりと書かれており、インデックスが関連しているため、それが問題であることがすぐにわかりました。 また、バグについては報告しませんでした。これは、ドキュメントに記載されていることであり、ディープマージにリンクしているためです。これは意図した動作であり、バグではありません。

私が言ったように、配列を浅くマージする方が直感的かもしれません。それがtsconfig _ itself_が実際に機能する方法だからです。 私は上記のリンクしたとして、 tsconfig _itself_あなたが追加したときに連結していませんexclude 、それが既存の上書きされますexclude 。

したがって、concatenateは、ドキュメント内の5つ以上の参照、マージの定義、デフォルトの定義、またはtsconfig自体の動作と一致しません。 そして、それは他のオプションの対称性とドキュメントを壊します。 それがどのように直感的かわかりません。

そして、何度も言ったように、オーバーライドするのではなく、非常に直感的でない連結にすると、特定のユースケースが

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

独自のexcludeを追加すると、設定したデフォルトが上書きされることが目的です。 デフォルトは、他のすべてのプロパティ名と同様に、プロパティ名を設定していない場合にのみ適用されます（これも、デフォルトの定義であり、すべてのライブラリでデフォルトがどのように機能するかです）。

これを連結に変更した場合、ユーザーはデフォルトのexcludeをオーバーライドする方法がなくなり、デフォルトをオーバーライドすることはtsconfigのデフォルトのexcludeも出荷しているため、 tsconfig _itself_で可能であっても、 tsconfigのデフォルトをオーバーライドすることは_不可能_になります。それ。

なぜ私がここで壊れた記録のように話しているのかわからないのですが、_エコシステム全体_で_既存の定義_と_既存の使用法_を繰り返しています。

@ agilgur5

そして、私が何度も言ったように、それをオーバーライドするのではなく、非常に直感的でない連結にします
特定のユースケースを不可能にします。 TSDXの使用法は次のとおりです。
https://github.com/jaredpalmer/tsdx/blob/17ffcd215f78a4e9d6936644cbeab332f6439088/src/createRollupConfig.ts#L149 -L178

この構成は簡単に中断される可能性があり、なぜこれがあなたに明らかでないのか理解できません。 ライブラリを壊れやすくしたくないので、この問題を作成しました。

面白いことに、 @ ezolenkoと私は、

デフォルトは、プロパティ名を設定していない場合にのみ適用されます

私はデフォルトの動作に同意し

デフォルトを上書きすることは不可能です

問題は、なぜユーザーはライブラリの作成者が禁止しているものにアクセスできる必要があるのか​​ということです。

上書きできないtsconfig構成を活用する必要がありますが、同時に、プリセットを拡張する機会を与える必要があります。 そしてこれが要点です。

解決策は、新しいAPIの設計にのみあります。

この構成は簡単に中断される可能性があり、なぜこれがあなたに明らかでないのか理解できません。 ライブラリを壊れやすくしたくないので、この問題を作成しました。

あなたは私がリモートで言わなかった言葉を私の口から取り出しています。 私はそれができないとは言いませんでしたし、壊れやすいとも言いませんでした。 _あなたの_ソリューションは、デフォルトの_エコシステム全体_やドキュメント自体の_既存の定義_にも_既存の使用法_にも一致しないと言ったばかりです。 デフォルトの定義全体を破ることは明らかに間違った振る舞いです。
私は何度か述べてきたように、私の提案は、浅いマージ配列の代わりに、すなわちにしたtsconfigオーバーライドtsconfigDefaults 、それはすべての非配列プロパティの場合と同様とのようにtsconfig _itself_作品。
何度か言ったように、それは重大な変更または非重大な変更で行うことができます。

口から言葉を出さないでください。 何度も繰り返しましたが、作り上げるのではなく、実際に書いたものを読んでください。

問題は、なぜユーザーはライブラリの作成者が禁止しているものにアクセスできる必要があるのか​​ということです。

tsconfigはそれを禁止していませんでした、TSDXはそれを禁止していませんでした、そしてrollup-plugin-typescript2もそれを禁止していなかったので、あなたが何を指しているのかわかりません。

上書きできないtsconfig構成を活用する必要がありますが、同時に、プリセットを拡張する機会を与える必要があります。 そしてこれが要点です。

解決策は、新しいAPIの設計にのみあります。

はい、これにtsconfigConcatオプションを追加できます。これは、「新しいAPI」になります。 デフォルトの定義全体を再発明することによって現在のAPIを破ると、一連の新しい問題と新しい直感的でない動作が作成されます。 ディープマージは配列にとって直感的ではないかもしれませんが、それでも_正しい_動作です。 連結は、デフォルトが意味するものではないため、単に間違った動作です。

tsconfigConcatはユースケースを解決し、名前に文字通り連結が含まれているため、より直感的です。
tsconfigDefaultsを「連結」を意味するように変更するのは、それが5回目、_デフォルトの意味ではない_ためではありません。

デフォルト= \ =連結。 それは私の意見ではありません、それが定義です。

@ agilgur5申し訳ありませんが、真剣に受け止めることはできません。
あなたの文章はすべて物議を醸しています、私はそれにうんざりしています。

私は単に、現在のAPIはそれを使った適切な作業をまったく許可していないと主張し、これがそれを変更する理由です。
もうこれを続けるつもりはありません。

さて、私は人々の口から言葉を取り出したり、実際の言葉を読んだり、物事を作り上げたり、寄稿者のキャラクターを攻撃したり、0のリンクを提供したり、0の選択肢を提供したり、単一のオプションのみを検討したり、他の選択肢を検討したりしませんでした、それはあなたでした。

助けようとしているだけで、実際の定義、実際のユースケース、および実際の代替案を提供している寄稿者を攻撃したい場合は、それがあなたの浸透していると思います：shrug：

私がその部分を書いているとき、私はlodashマージが実際に配列をマージする（それらをインターリーブするか何か）という印象を受けていたと思います。 または、配列に何が起こるかについても注意を払っていませんでした。 インデックスを要素名として使用して配列の内容を上書きするようです（そうですか？配列は元々真の配列ではなく、たまたまキーの番号が付いた辞書であるというjavascriptのことですか？）、現時点でのドキュメントはあります。

理想的には、デフォルト/メイン/オーバーライドのtsconfigsオプションにより、スカラー値と配列の両方のすべてのパラメーターを同じ驚くべき方法でカスタマイズできるようにする必要があります。 インデックスに基づいて配列要素を置き換えるLodashの方法には、1つの大きな欠点があります。リテラルのスパース配列を作成できないことです（ undefinedの束で配列をパディングする可能性がありますか？）。 つまり、ロールアップ構成は動的に構築する必要があり、jsonファイルであるtsconfigはそれらをまったく実行できません。

リテラルのスパース配列を使用しても、インデックスに基づいて要素を置き換えることは非常に脆弱です。

一方、通常このように動作するものが他にない場合、連結は驚くべきことです。 そして、それだけでは以前の値を削除することはできません。

私が最初に提案したように連結と置換を切り替えることは、二重に驚くべきことです。

@ agilgur5が提案したように、両方のマージを変更して配列を大規模に置き換えることは、おそらく最も驚くべきオプションではありません。保持したい値を繰り返す必要がありますが、値を削除できます。 ただし、これはまだ重大な変更であり、そのための構成を書き直す必要があります（https://xkcd.com/1172/を参照）。

これらのオプションの動作を変更するか、新しいセットを作成して既存のオプションを非推奨にして警告を表示することができます。

（どこかで重要なポイントを逃した場合は申し訳ありませんが、スレッド全体をスキップしただけです）

@ezolenko次の方法がわかります

状況と動機を見てみましょう：
開発者は、ロールアッププラグインを介してtypescriptに必要な構成をいくつか追加したいと考えています。
この場合、開発者が設定を安全に追加することを妨げたり、構成とロールアップ構成をマージするときに他の設定を失ったりしないようにする必要があります。

これは私たちに何を伝えますか？ セマンティクスから始めましょう：

前にも言ったように

私はデフォルトの動作に同意します。 tsconfigに対応するプロパティがない場合にのみconfigdefaultを適用することは理にかなっています...

これを完全に再設計することができます。

私の提案は次のとおりです。

1. 元のtsconfig対応するプロパティがない場合は、 tsconfigDefaultsプロパティを適用します。
2. tsconfigOverrideがこれを処理する必要があります。
   2.1スカラー値で以前と同じように機能するはずです。
   2.2配列のプロパティを連結する必要があります。 （おそらく、これは何も壊してはならず、構成の動機を満たさなければなりません）

3番目の追加のrpt2オプションを避けようとしています。これは、このAPIを少なくとも50％複雑にし、開発者はこれを理解できなくなるためです。

@ agilgur5あなたが言う現実と言葉が同じものではないのは素晴らしいことです。

また、メール通知のおかげで、8回編集せずに元のメッセージを読んで、人の目には良く見えるようにしました。
誰もあなたを攻撃したくなかった、さらに、誰もそれをしなかった。
あなたは単に攻撃的であることをやめ、このスレッドで矛盾したスピーチを書くことをやめるように求められました。

• 0リンク-私は問題を理解し、それを完全に説明し、例を示し、さらにはスクリーンショットを与えるために多くの時間を費やしました。 また、TSDXについても調べたところ、確認したため、構成が壊れやすいとのことでした。 そして最も重要なことに、私は黙っていませんでしたが、これに直面している人々のために問題をエスカレートするためにこの問題を作成しました。
• 0の選択肢-注意深くお読みください。 私は最初のメッセージから解決策を提供し始めました。
• 言葉を出す-落ち着いて、少なくともこのスレッドでは自己陶酔的であることをやめなさい、私がこのように働くのは不快です。

@maktarsisどのようにあなたのアプローチで開発者はtsconfigから包含または除外エントリを削除することができますか？ シナリオは次のとおりです。他の場所で使用されているtsconfig.jsonがあり、json自体に触れずにロールアップで使用したいが、何らかの理由で除外配列から行を削除したい。

@ezolenko私はあなたのことを理解しました。

当然、上記のように、これは不可能です。
しかし、私たちはモチベーションではなく可能性について話しているのです。

除外を書き直す必要がある状況はまだわかりません。
それでも、開発者の「除外」を上書きする必要はないと私は考えています。 言い換えれば、私はその理由を想像することはできません。
「何らかの理由で」の理由を理解する必要があります。

いずれにせよこの可能性を持たせたい場合は、連結用の追加のAPIを提供する必要があります。
しかし、ご存知かもしれませんが、それは請求されておらず、単に不要かもしれないと思います。
「除外」から何かを除外する必要はまったくないかもしれませんが、逆にすると、構成の理解が複雑になります。

配列に存在しないものを追加することと、配列から何かを削除することの両方が必要です。 浅いマージでは、追加と削除の両方が、アレイ全体を（変更を加えて）より高いレベルで複製することによって行われます。 あまり便利ではありませんが、使いやすいです。

これは"esModuleInterop": trueの場合にも当てはまり、一部の環境ではライブラリが機能しなくなりました。

config.jsonの役に立たないコンパイラオプション：

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

rollup-configの便利なコンパイラオプション：

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

@maktarsisの最初の提案は、私にとって予想される動作でした：

元のtsconfigに対応するプロパティがない場合は、tsconfigDefaultsプロパティを適用します。

^上記のコメントはincludeまたは配列用でtsconfigDefaultsすでに行っていることです。
また、私とTSDXはesModuleInterop多用しているので、 tsconfig.jsonで機能することはわかっていますが、そのコメントが何を意味するのかわかりません。 投稿された設定にもcompilerOptionsがありません。次のようになります。

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

しかし、それは意図したとおりにオーバーライドして機能します。

ここで、浅いマージがこのリポジトリで数回言及されていることに注意してください：＃86（ここで行ったように、TSの浅いマージ動作について言及しています）、 https：//github.com/ezolenko/rollup-plugin-typescript2/issues/72 #issuecomment -383242460、およびhttps://github.com/ezolenko/rollup-plugin-typescript2/issues/208#issuecomment -594237841