12

数か月前に初めて webJars を発見したとき、これらのビルド/ビルドシステムの一部が非常に複雑であり、jsファイルが公開される頻度を考えると、それがクライアント側の依存関係を処理する実行可能な方法であることに非常に懐疑的でした。2 番目の懸念はもちろん十分に根拠のあるものではありませんでしたが、約 10 個scss/css/lessの 型の webJars と 8 個の JS webJars を 1 つのjsDependencies屋根の下に配置しようとして 36 時間近く費やした結果、最初の懸念が正しかったと感じています。

私が見つけたのは、JS 依存関係 3、4、または 5 に到達するまでに、ばかげたタイムキル ループに陥り始めることです。

1.「ああ、webjar の依存関係と同じ名前のランダムなファイルがあったため、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] - 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の男の子。

これは何度も何度も何度も繰り返され、それから私はやり始めなければなりません

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依存関係があり、それを変更することはできません...

質問

うーん？以前と同じように、アプリなしで依存関係を巨大なファイルまたはファイルのセットにビルドし、それをビルドにフィードした場合はどうなりますか? 私はオンラインからの概念実証を持っていて、それを機能させました（ https://github.com/wav/material-ui-scalajs-react/blob/master/src/main/scala/wav/web/だったと思いますmuiwrapper/package.scala ) はほとんど機能し、私にアイ​​デアを与えてくれました。

npmよりもはるかにうまく機能することはわかってsbt,いますが、それでもパッケージに入れることができます...マイナス面は何ですか? sbt について何か不足していますか?

4

2 に答える 2

12

仰るとおりです。アプリケーションが JavaScript ライブラリに重要な依存関係を持ち始めると、jsDependenciesスケーリングしません。これは主に、WebJars に (推移的な依存関係と同様に) 重要な機能が欠けているためですが、スケーリングjsDependenciesするように設計されたメカニズムではなかったためでもあります。

時間が経つにつれて、ユーザーは のより多くの機能を求めるようjsDependenciesになりました。それは、真のアプリ規模の (それが何を意味するにせよ) 依存関係メカニズムとしてそれを使用したいからです。その結果、より多くの機能/ハックにパッチを適用してきましたjsDependencies。結果は世界で最も美しいものではなく、間違いなく欠点があります.

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

于 2016-09-17T17:48:53.070 に答える
3

私の意見では、Web jar を使用する主な利点は、npm を使用する必要がないことです。さらに、通常の Maven 解決/ダウンロード プロセスを実行するため、完全ではありませんが、破損のパイプラインは 2 つではなく 1 つだけです。

とにかく、彼らは痛みを伴うことがあります。私の scala.js アプリには約 30 の依存関係があり、それらはほとんど Web jar で管理されています。一般に、npm webjar と bower webjar を使用した方が良い結果が得られることがわかりました。また、web jar の推移的な依存関係に依存しようとするのは愚かなことです。

私の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"

最初に注意すべきことは、基本的にこれまでに依存するすべてのものにぶら下がっているバージョン番号です。使い慣れたら、バージョンを変数に取り出します。2 つ目はintransitive()注釈です。それがなくてもうまくいくこともありますが、明示的であることで物事が機能し、髪が所定の位置に保たれることがわかりました。

私は、react や angular などのフロントエンドに適したパッケージに固執する傾向があります。新しい反応ライブラリの中には、数十の推移的な依存関係があり、それらを使用しようとするのは面倒です。私はそれらを避けます =p

于 2016-09-17T22:09:33.420 に答える