Rollup-plugin-typescript2: `input`ロールアップとしてオブジェクト内の間違ったフォルダに生成されたファイルを入力します

useTsconfigDeclarationDirプラグインオプションは、今のところ回避策です。

これは、0.20.0でリリースされた＃142で修正される可能性があります

こんにちは@ ezolenkom ＆ @ jakearchibald 、実際にはどちらも運がありません。

ロールアッププラグインにuseTsconfigDeclarationDirオプションを追加すると、宣言ファイルはまったく作成されなくなります。 残念ながら、0.20.1にアップデートしても違いはありませんでした。

@benkeen useTsconfigDeclarationDir: trueプラグインオプションを使用する場合は、 tsconfig.json declarationDir値も必要です。

同様の問題があります。私のプロジェクトのレイアウトは次のようになります。

export default [ 
  {
    input: 'src/subFolder1/one.ts,
    output: [
                    {
                      file: 'dist/one.js'
                      .....                      
                     }
    ],
    plugins: [
           typescript({
                typescript: require('typescript'),
            }),
    ]
  },
      input: 'src/subFolder2/two.ts,
      output: [
                    {
                      file: 'dist/two.js'
                      .....                      
                     }
    ],
     ...
  },
]

出力として私は持っています：

  |---subFolder1
  |          |--------one.d.ts
  |
  |---subFolder2
  |          |---------two.d.ts
  |-----one.js
  |-----two.js

useTsconfigDeclarationDir: false 0.20.1で動作します-d.tsファイルはoutput.[].dir指定されたフォルダーに移動します。 @benkeenもう一度やり直していただけませんか？

@AntonPilyakは設計によるものです。d.tsがサブパスなしで1つのフォルダーに入る場合、 subFolder1/one.tsとsubFolder2/one.ts 、そのうちの1つが別のフォルダーを上書きします。

@ezolenko ：この機能は、実際の問題を解決するのではなく、より多くの不便を生み出すと思います（これらすべてのディレクトリ構造を維持するのは難しいため）。 簡単に含めることができるバンドルを作成するには、これらすべての型宣言をバンドルのルートにコピーするスクリプトを作成し、ディレクトリを.npmignoreに追加する必要があります。 これらの追加のディレクトリは、同じ名前のタイプファイルに対してのみ作成することをお勧めします。 残りは、rollup.config.jsonの「output」セクションで定義されているディレクトリを使用します。

@AntonPilyak useTsconfigDeclarationDir: trueオプションを使用して、tsconfigでdeclarationDirを設定できる場合があります。これにより、typescript自体が入力出力パスを処理できるようになります。

パスの一意性に基づいてサブディレクトリを使用するかどうかを決定することは、進化するプロジェクトでは悪夢になります。別のフォルダに同じ名前の新しいファイルを追加したために、突然入力がサブフォルダに移動します。

通常、きれいな型付けが必要な場合は、とにかくそれらを1つのファイルにマージする必要があります（その名前を忘れ続けているnpmモジュールがありました）

私はバージョン0.22.0を使用していますが、 @ AntonPilyakとほぼ同じ問題があり

{
    ...
    input: {
        foo: 'src/lorem/foo.ts',
        bar: 'src/ipsum/bar.ts'
    },
    output: {
        dir: 'dist',
        format: 'cjs',
        sourcemap: true,
    }
}

そして、私はこれを出します：

dist/
    lorem/
        foo.d.ts
    ipsum/
        bar.d.ts
    foo.js
    foo.js.map
    bar.js
    bar.js.map

明らかに、 *.d.tsファイルを*.js *.js.mapファイルと

useTsconfigDeclarationDirとdeclarationDirをいじってみましたが無駄になりました。

定義ファイルは常にそれぞれloremとipsumサブフォルダー内にあり、フラットリストにはなりません。

さらに、エントリポイントだけでなく、見つかったすべての.tsファイルに対して宣言ファイルを作成しているようです。

dist/
    lorem/
        foo.d.ts
    ipsum/
        utils/
            bar-helper.d.ts
        bar.d.ts
     some_other_ts_file/
         not_imported_by/
             neither_foo_nor_bar/
                  wat.d.ts
    foo.js
    foo.js.map
    bar.js
    bar.js.map

options.tsconfigOverride.inputをエントリポイントだけにスコープしようとしましたが、それは何の効果もないようです。 実際、 tsconfigOverride.inputがまったく機能するかどうかさえわかりません。

これはすべて少し混乱します。

..。

つまり、 utils/bar-helper.ts宣言ファイルを作成する必要がある場合は十分に公平ですが、少なくともwat.tsは全体から

ええ、それはtsconfigによって見つけられたすべてのファイルの宣言を生成します。特定のファイルに触れたくない場合は、それがtsconfigに除外されているか含まれていないことを確認してください。 typescriptで見つかったファイルのリストを表示するには、冗長性3でプラグインを実行し、「解析されたtsconfig」エントリを探します。

定義パスの場合、例のどこに'src/ipsum/foo.ts'定義を配置しますか？

これはdist/foo.js定義であるため、ソースマップファイルと同じように、つまりdist/foo.d.ts横に配置されると思いました。

TypeScriptはdist/foo.jsとdist/lorem/foo.d.tsをペアにすることを知っていますか？

これが崩壊する完全なシナリオは次のとおりです。
src / dir1 / foo.ts
src / dir2 / foo.ts

dir1 / foo.tsをロールアップ入力として設定すると、dir2 /foo.tsがインポートされます。 ロールアップは、両方のソースファイルの関連部分を含むdist / foo.jsバンドルを作成しますが、typescriptは、同じ名前の2つのタイプ定義ファイルをどこかに作成する必要があります。

簡単な解決策は、ソースレイアウトをミラーリングしてサブフォルダーを使用することです。 型定義をマージするように指示しない限り、 tscも同様に機能すると思います（rpt2は定義のマージをサポートしていません）。

そして、はい、typescriptはタイプ定義を見つける場所を知っています。 したがって、少し厄介であることを除けば、これは問題にはならないはずです。 あなたはNPMのタイプとパッケージを展開したい場合は、設定"types"でpackage.jsonあなたのエントリポイントのためd.tsファイルに。 Typescriptはそこから物事を見つけます。

ああ、このプラグインは宣言ビルドプロセスのどの部分も実際には管理していません。 Rollupのプロセスとは関係なく、 tscを起動してその処理を実行しますか？

それでも、いくつかのモジュールのみを公開/公開している場合、TypeScriptで検出されたすべてのtsファイルに対して*.d.tsファイルを生成する必要があるのはなぜですか？ エントリポイントだけに制限する方法はありませんか？

つまり、スタンドアロンモジュールのセット（ import tool1 from 'myTools/tool1';など）をエクスポートしているので、 pkg.types使用する単一のエントリポイントはありません。 各定義ファイルは、VSCodeがそれを取得するために、対応する*.js隣に存在する必要があります。

さらに悪いことに、私が持っている場合

{
    ...
    input: {
        fooscript: 'src/foo/index.ts',
        barscript: 'src/bar/index.ts'
    },
    output: {
        dir: 'dist',
        format: 'cjs',
        sourcemap: true,
    }
}

私は得る：

dist/
    foo/
        index.d.ts
    bar/
        index.d.ts
    fooscript.js
    fooscript.js.map
    barscript.js
    barscript.js.map

そして今、TypeScriptがdist/fooscript.jsとdist/foo/index.d.tsをペアにする方法はありません。

..。

プラグインがTypeScriptに各JavaScriptバンドルファイルの宛先/出力パスを供給する方法はありませんか？ tscは元のエントリのファイル名を受け取り、宣言を生成するときにそれをしっかりと保持しているようです。
...または、入力ファイルごとに、対応する*.d.tsファイルを探し、それを入力ファイルマップの宛先に移動して名前を変更します。 （あなたは私がここで私のお尻から話していることに気付くかもしれません、それで... ;-)

これは、ロールアップが終了した後に手動で試してみる必要があるものですが、プラグインが自動的に処理するのであれば、はるかに便利です。

いいえ、プラグインはLanguageServicesを使用します（通常、同じtypescript API IDEが使用します）。そのため、何をどこに書き込むかをある程度制御できます。

ロールアップ入力ごとに1つの型定義を作成するには、その入力のすべてのインポートの定義をマージする必要があります。 ロールアップは1つの入力tsファイルを参照している可能性がありますが、それをビルドするときに任意の数のソースファイルをインポートしてバンドルしている可能性があり、それらにも生成されたタイプが必要です。

現在、tsconfigファイルを見たときにtypescriptが見つけるすべての定義を生成する側に誤りがあります。 トランスパイルされたモジュールに対してのみ型を生成すると、型のみのファイルは無視されます。

その部分を再検討する必要があるかもしれません。その部分が完了してからAPIが大幅に変更されました...

私はあなたの例を機能させる方法を見る必要があります。 1つのロールアップ構成で複数のバンドルをより適切にサポートする必要がある場合があります。

それを構築した後、どのようにそのパッケージを消費しますか？ npmで公開し、パッケージ名でインポートできるものではありません...

スタンドアロンユーティリティのコレクションを作成しています。 公開/インストールされたパッケージのルートフォルダーには、ビルドされたすべてのモジュールファイルがフラットリストに含まれています。

（私はそれらをネストされたフォルダー構造のTS / ES6で記述し、テストファイルを混合し、ロールアップを使用して、コード分割とインライン化を効率的に組み合わせたCJSファイルのフラットリストに変換します。共有コード。）

次に、これらのツールをファイル名でインポートして使用します–次のようになります。

import tool1 from 'myTools/tool1';
import tool2 from 'myTools/tool2';

ツールキット全体に単一のエントリポイントがない（ pkg.mainまたはpkg.moduleエントリがない）ことで、めったに使用されない、さらには実験的なツールを自由に追加できるという考え方です。下流の消費者のために重み/膨満感を追加することなく（効率的なツリーシェーキングがない可能性があります）。

...コマンドラインでtscを少し使ってみましたが、あなたが扱っている制限がわかったと思います。

ただし、tscを実行し、モジュール/出力形式を"amd"または"system"に設定すると、すべての適切なリストを含む単一の*.d.tsファイルが生成されることに気付きました。必要なdeclare module "..."ブロックがインライン化されています。

この動作が何らかの形で悪用される可能性があるのではないかと思います-ファイルの名前変更/移動および最後の（メイン）モジュール宣言のアンラップ/書き換えを介して？

補足： tscは、その宣言ファイルのツリーシェイクにあまり力を入れていないようです。 あるケースでは、単一の非常に単純な関数シグネチャをエクスポートするメイン（エントリポイント）モジュールがありますが、宣言ファイルは「舞台裏」で使用されるすべてのプライベートモジュールの宣言ブロックを公開しています。 面白い。 :-)

また会ったね。
今のところ、 tscにカスタムdeclarationDirを設定して、すべての*.d.tsをにダンプしてから、同じエントリファイルをインポートするスタンドアロンスクリプトを実行します。 Rollupにフィードする際のoutput-fileオブジェクト。これにより、実際の宣言ファイルをexport * fromするだけのバンドル宛先レベルの宣言ファイルが生成されます。

基本的に、次のものだけを含むdist/fooscript.d.tsを生成します。

export *  from './__types/foo/index';

これは醜いスタンドアロンのハックですが、予想どおりに正しい結果が得られます。

rollup-plugin-typescript2同じようなことができるのだろうか？

ええ、それはうまくいくでしょう。

私にはいくつかのアイデアがあります（私がそれらに近づいたとき）。たとえば、関係する各d.tsに対して/// <reference types=""/>束を持つ<bundlename>.d.tsを生成します。

まず、あまりにも多くの型宣言を生成するという関連するバグを修正し、それをルートファイルとそれが実際にインポートするものだけに制限する必要があるかもしれません。

いくつかの考え：

IMO、私のハックの唯一の本当に醜い部分は、それがロールアッププロセスとは一線を画しているという事実です。 中間の*.d.tsは、実際には、Rollupの生成されたバンドルとtscの定義の間を橋渡しする非常に巧妙で慣用的な方法です。

tsc生成された宣言ファイルは相対パスを介して相互に参照するため、そのファイル/フォルダー構造はおそらくそのままにしておくのが最善です。カスタム言語構文のために、Rollupの機能の一部を再実装することになりません。

そして、 rollup-plugin-typescript2がoutput.dir + '__types'ようなものをデフォルトのdeclarationDirとして設定すると、 tscの過度の熱意によって引き起こされた混乱はきちんと一掃されます。明確に名前が付けられたフォルダ内の光景。 そうすれば、無関係な定義ファイルはIMOにとって非常に小さな問題になります。

FWIW、これが私のスクリプトの要点です。

const { makeInputMap, getEntrypoints, distFolder, srcFolder } = require('./buildHelpers');
const { writeFileSync } = require('fs');
const { relative } = require('path');

const srcPrefixRe = new RegExp('^' + srcFolder + '/');
const tsExtRe = /\.tsx?$/;

const declDirRelative = './' + relative(
  distFolder,
  require('../tsconfig.json').compilerOptions.declarationDir
);

const tsEntrypoints = getEntrypoints()
  .filter((fileName) => tsExtRe.test(fileName));

Object.entries(makeInputMap(tsEntrypoints))
  .forEach(([moduleName, sourcePath]) => {
    const tscDeclFile = sourcePath
      .replace(srcPrefixRe, declDirRelative + '/')
      .replace(tsExtRe, '');
    const outFile = distFolder + '/' + moduleName + '.d.ts';
    writeFileSync(
      outFile,
      [
        'export * from "' + tscDeclFile + '";',
        'import x from "' + tscDeclFile + '";',
        'export default x;',
        '',
      ].join('\n')
    );
  });

console.info('Created local declaration files for TypeScripted entrypoints.');

デフォルトのエクスポートを明示的に再エクスポートする必要があるように思われるため、上記の例を更新しました。

予備テストでは、 defaultエクスポートのない宣言ファイルからdefaultを盲目的に再エクスポートしても無害であり、黙って無視されることが示されています。 （少なくともVSCodeによる。）

こんにちは、この問題はv0.23.0で解決する必要がありますか？

（...すべてのカスタムファフィングを削除するためにプロジェクトを更新する必要があるかどうか疑問に思っています）

0.23は、表示されているすべての宣言を生成しませんが、相対的なサブフォルダーに実際にインポートする宣言を生成します。 おそらく更新してより軽い型にすることができますが、ルート型宣言を生成するものはまだありません。

私のカスタム回避策ビルドスクリプト（上記を参照）は、ますます多くのプロジェクトに徐々に忍び寄っています。 o_O

参考：公式の@ rollup / plugin-typescriptパッケージの開発が再開され、タイプチェックと宣言ファイルの出力機能が追加されたので、個人的にそれを使用するように切り替えています。
ただし、制限はほとんど同じです。

@maranomynetロールアップが実行された後も、宣言ファイルを移動するためにスクリプトに依存していますか？ 私は自分自身を切り替える運があまりありませんでした。

うん。 tscエンドツーエンドのバンドルを行わせない限り、これが唯一の方法のようです。
これらのロールアッププラグインは、tscに2つの異なるタスクを実行するように効果的に要求しているようです。

1. 「これらすべての個々のモジュールをタイプチェックしてJavaScriptに変換します」そして、私（つまりロールアップ）にバンドルとディスクへの書き込みをさせてください。
2. 「このTSプロジェクトフォルダーのすべての宣言を作成し、そこにダンプします。」

1と2の結果は一致せず、「入力マップ」やコード分割などを使用している場合は一致しません。–AFAICT。

...ロールアッププラグインを型宣言の生成プロセスにさらに関与させない限り。

そうそう、それは私が考えたようなものです、ありがとう！ あなたの役に立つ答えのためにあなたに👍を与えました、そして👎は私がそれについてどう感じるかのためです。

これで運がいいですか？

@maranomynetや私と同じsrcフォルダー構造を持つ苦労している魂のために。

私はそれの簡単な修正に出くわしました、別の醜い方法かもしれませんが、私にとってはうまくいきます。

私はrollup-plugin / typescript2を使用しているので、この回答ではその構成を使用します。
tsconfig.jsonで独自のdeclarationDirを定義して、プロジェクトがバンドルされたdistの独自のパスにあるすべての* .d.tsファイルをダンプできるようにします。 また、ロールアップ構成ファイルのtypescriptプラグインでuseTsConfigDeclarationDirをtrueに設定してください。
また、rollup.config.js（およびpackage.json）で個々のコンポーネントバンドルの出力パスを定義する場合は、それらのパスを「declarationDir」+「srcコンポーネントルートの状態」と同じになるように変更します。 したがって、srcのコンポーネントが次のような場合：

src / homepage / foo.tsx

そして、declarationDirは次のとおりです。

dist / MyDeclarationDir

したがって、出力パスは次のようにする必要があります。

dist / MyDeclarationDir / homepage / foo.js

このように、ロールアップはコンポーネントmain.jsと同じディレクトリにタイプを含め、TSコンシューマープロジェクトはタイプを取得します。

したがって、バンドルは次のようになります。

dist /

    declarationDirPath/
                  component1/
                        foo.js/
                              foo.js
                              foo.map.js
                        foo.d.ts
                   component2/
                        bar.js/
                               bar.js
                               bar.map.js
                        bar.d.ts