ScalaJs sbtビルドでは、npmまたはbowerの代わりにWebjarsを 'Provided'で使用する利点はありますか？

Question

私が数ヶ月前にwebJarsを初めて発見したとき、私は、これらのビルド/ビルドシステムのいくつかの巨大な複雑さを考慮すると、クライアント側の依存関係を処理する実行可能な方法であり、公開されています。第二の懸念は当然確立されていませんでしたが、約36時間を費やして、最初に肯定的に感じています。scss/css/lessタイプのwebJarsと8つのJSウェブジャーナルを1つのjsDependencies屋根の下に置くことは無駄です。

私はあなたがJSの依存関係3、4、または5に達するまでにそのよう見つけたもの、あなたはとんでもないtimekillループに取得を開始：

1.「いくつかのランダムなファイルがあったので番号ああfastOptJSが失敗しました！それはwebjarの依存関係と同じ名前になっています！ "

[trace] Stack trace suppressed: run last client/compile:resolvedJSDependencies for the full output. 
[error] (client/compile:resolvedJSDependencies) org.scalajs.core.tools.jsdep.JSLibResolveException: Some references to JS libraries could not be resolved: 
[error] - Ambiguous reference to a JS library: bootstrap.min.js 
[error] Possible paths found on the classpath: 
[error] - META-INF/resources/webjars/bootstrap/3.3.6/js/bootstrap.min.js 
[error] - META-INF/resources/webjars/bootstrap3-dialog/1.34.4/examples/assets/bootstrap/js/bootstrap.min.js 
[error] originating from: client:compile, client:compile, client:compile, client:compile 
[error] - Ambiguous reference to a JS library: bootstrap.js 
[error] Possible paths found on the classpath: 
[error] - META-INF/resources/webjars/bootstrap3-dialog/1.34.4/examples/assets/bootstrap/js/bootstrap.js 
[error] - META-INF/resources/webjars/bootstrap/3.3.6/js/bootstrap.js 
[error] originating from: client:compile, client:compile, client:compile, client:compile 

2.私は何をすべきか知っています！私は、定義されたjsにバージョンを追加します！

lazy val   webjarbs = "org.webjars"    % "bootstrap"      % version.bootstrap/s"${version.bootstrap}/bootstrap.js"      minified s"${version.bootstrap}/bootstrap.min.js"   dependsOn "jquery.js" commonJSName "bootstrap" 

3.「ああ、いいえ！fastOptJSが失敗しました！」

[trace] Stack trace suppressed: run last client/compile:resolvedJSDependencies for the full output. 
[error] (client/compile:resolvedJSDependencies) org.scalajs.core.tools.jsdep.JSLibResolveException: Some references to JS libraries could not be resolved: 
[error] - Missing JS library: 3.3.6/bootstrap.js 
[error] originating from: client:compile, client:compile, client:compile, client:compile 
[error] - Missing JS library: 3.3.6/bootstrap.min.js 
[error] originating from: client:compile, client:compile, client:compile, client:compile 

gg boys。

これは何度もして周りと一周した後、私は

lazy val   bs_sidebar = ("org.webjars"    % "bootstrap-sidebar"    % version.bs_sidebar intransitive())/"js/sidebar.js" dependsOn(s"bootstrap.js", s"bootstrap.min.js") 

をやって起動する必要があり、今私は本当にさえwebjarを使用してないんだけど、それはXという名前JS依存関係を持っています私はそれを変更することはできません...

質問

Hmmm？私がやったことをやっただけで、アプリケーションなしで依存ファイルをいくつかの巨大なファイルやファイルのセットにして、それをビルドにフィードするとどうなりますか？私はオンラインからコンセプトの証拠を持っており、私はそれが仕事になった（私はそれがほとんどだったと思うそれはhttps://github.com/wav/material-ui-scalajs-react/blob/master/src/main/scala/wav/web/muiwrapper/package.scalaだった）、そして私にアイデアをくれた。私が知っているnpm

はsbt,よりもずっと良く動作し、私はまだ私のパッケージにそれを得ることができます...何欠点だ、とは私がSBTについて何かが足りないのですか？

Answer 1

私はあなたに同意します。アプリケーションがJavaScriptライブラリに依存しないようになると、jsDependenciesは拡大縮小されません。これは主に、WebJarsに重要な機能がない（推移的な依存関係と同じように）欠点があるためですが、jsDependenciesはスケーリングの仕組みではなかったためです。

時間がたつにつれて、ユーザーはjsDependenciesというより多くの機能を求めてきました。なぜなら、それは本当のアプリスケール（それが意味するものであれ）の依存性メカニズムとして使用したいからです。その結果、我々はより多くの機能/ハックをjsDependenciesの上にパッチしてきました。その結果は世界で最も美しいものではなく、間違いなく欠点があります。

特に、あなたがそれに精通していて、それをワークフローに統合する方法を知っている場合は、npmを使用して依存関係を解決することをお勧めします。

Answer 2

ウェブジャーを使用する主な利点は、私の意見では、npmを使用する必要はないということです。さらに、通常のMaven解決/ダウンロードプロセスを経るため、完全ではないものの、2つではなく1つの破損パイプラインに過ぎません。

それにかかわらず、痛いことがあります。私はscala.jsアプリに約30の依存関係があり、ほとんどがウェブジャーで管理されています。私は、一般的に、npm webjarsとbower webjarsを使用してより良い結果を得ていることを発見しました。ウェブジャー推移依存に依存しようとするのは愚かです。

私jsDependenciesは次のように見える傾向：

("org.webjars" % "morrisjs" % "0.5.1" intransitive()) 
     /"morris.js" 
     minified "morris.min.js" 
     dependsOn "2.1.2/raphael.js", 
("org.webjars" % "raphaeljs" % "2.1.2-1" intransitive()) 
     /"2.1.2/raphael.js" 
     minified "2.1.2/raphael-min.js" 

注意すべき最初の事は今までに依存します基本的にすべてのものの上にマングルバージョン番号です。多く使用されると、バージョンを変数に抽出します。もう1つはintransitive()アノテーションです。私は時々それなしで逃げることができますが、私は明示的であることが物事を働かせ、私の髪を適所に保つことがわかります。

私は反応や角度のようなフロントエンドのフレンドリーなパッケージに固執する傾向があります。新しい反応ライブラリーのいくつかには、数十の推移的な依存性があり、それらを使用しようとすると痛いでしょう。私はそれらを避ける=