babel-plugin-transform-runtimeプラグインを使用している場合、私のコードはすべてのヘルパー関数をインラインにする代わりにimport/requirebabel-runtimeになります。これは素晴らしいですが、私の図書館に依存性がありますbabel-runtime。私がやりたいことは、Babelに1つの余分なファイル（./babel-runtime）を抽出させ、それを他の出力ファイルにドロップして、外部のの依存関係に含める必要はありません。つまり、私のライブラリが使用されているどこにいても、それをpackage.jsonに追加する必要はありません。これは可能ですか？外部依存関係のないbabel-runtime transformの使い方は？
あなたはtransform-runtimeプラグインでmoduleNameオプションを使用して代わりにbabel-runtimeのカスタムモジュールをインポートすることができます：私が見つけ
{
"plugins": [
["transform-runtime", {
"moduleName": "./babel-runtime"
}]
]
}
ライブラリのディレクトリ構造がフラットでない場合、モジュールのパスが壊れてしまいます。また、 'node_modules'の' babel-runtime'を私のdistにコピーすることをお勧めしますか？ – mpen
@mpenはい。外部依存として 'babel-runtime'を使いたくないと言ったので、ローカルモジュールとして使うことができます。しかし、多分私はあなたの質問を誤解した。実際に達成しようとしていることを説明できますか？外部依存として 'babel-runtime'を含むことに何が問題になっていますか？ –
ライブラリを作成し、それがbabel-runtimeに依存する場合は、ライブラリを使用する人も誰でもインストールする必要があります。私はそれが "ピア依存関係"になると思う。私は小さなユーティリティライブラリに依存したくない。それがモノリシックなプロジェクトだったなら、確かに、いくつかの追加のdepsは大したことではありませんが、小さなヘルパー関数のセットでは、それはうまくいきません。 lodashにbabel-runtimeが必要かどうかを想像してください。 – mpen
唯一の解決策はがbabel-plugin-transform-runtimeプラグインを使用して、あなたの設定にexclude: ['transform-regenerator']を追加しないにしました。これにより、Babelがリジェネレータに依存するのを防ぐことができます。また、古いブラウザではコードが実行されないことを意味します。
古いブラウザのサポートが必要な場合は、fast-asyncを試すことができます。インデックスファイルの依存関係をインライン展開する方法はあると言いますが、まだ試していません。私はこれがブラウザがPromisesをサポートしているが、async/awaitはサポートしていないと仮定していると思う。
webpackまたはロールアップでコードをバンドルしないとこの問題は解決しますか？ –
@MichałPerłakowskiまあ、私はそれを事前にwebpackしたくないです。アイデアは、私のライブラリをES6モジュールとして配布して、消費者がそれを握手できるようにすることです。ロールアップがどのようにランタイム依存性を回避するかは不明です。 – mpen