В сборке ScalaJs sbt есть ли какие-либо преимущества для использования webjars вместо npm или bower с помощью "Provided"?

Когда я впервые обнаружил webJars несколько месяцев назад, я был очень скептичен, что было бы жизнеспособным способом обработки клиентских зависимостей, учитывая огромную сложность некоторых из этих сборщиков/сборных систем и учитывая частоту, которая js публикуются. Вторая проблема была, конечно, не обоснованной, но я чувствую себя оправданным в первую очередь, потратив почти 36 часов, тщетно пытаясь получить около 10 scss/css/less -типов webJars и 8 JS webJars, чтобы жить под одной крышей jsDependencies.

То, что я обнаружил, когда вы достигли зависимости JS 3, 4 или 5, вы начинаете входить в смешной цикл timekill:

1. "Oh nos! 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, но у него есть зависимость js с именем X, и я не могу изменить это...

Вопрос

Ммм? Что делать, если я просто делал то, что раньше делал, но создавал зависимости без приложения в какой-то гигантский файл или набор файлов, а затем загружал их в сборку? У меня есть доказательство концепции из онлайн, и я получил его работу (я думаю, что это был https://github.com/wav/material-ui-scalajs-react/blob/master/src/main/scala/wav/web/muiwrapper/package.scala), который почти сработал, и дал мне эту идею.

Я знаю, что npm работает намного лучше, чем sbt,, и я все еще могу получить его в свой пакет... что недостаток, а я что-то пропустил о sbt?

Ответ 1

Я согласен с тобой. Когда приложение начинает иметь нетривиальные зависимости от библиотек JavaScript, jsDependencies не масштабируется. Это связано главным образом с тем, что WebJars не хватает критических функций (как транзитивных зависимостей), но также потому, что jsDependencies не был механизмом, предназначенным для масштабирования.

С течением времени пользователи запрашивали все больше и больше функций jsDependencies, потому что они хотят использовать его как свой механизм зависимостей приложения (независимо от того, что это означает). В результате мы исправляем все больше и больше функций/хаков поверх jsDependencies. Результат - не самая красивая вещь в мире, и она определенно имеет недостатки.

Я бы рекомендовал использовать npm для разрешения ваших зависимостей, особенно если вы знакомы с ним и знаете, как интегрировать его в свой рабочий процесс.

Ответ 2

Основным преимуществом использования веб-банок, на мой взгляд, не является необходимость использования npm. Кроме того, они проходят обычную процедуру разрешения/загрузки maven, поэтому, хотя она не идеальна, это только один конвейер разлома вместо двух.

Несмотря на это, они могут быть болезненными. У меня около 30 зависимостей в моем приложении scala.js, и они в основном управляются с помощью веб-баннеров. Я обнаружил, что, в общем, я получаю лучшие результаты, используя npm webjars vs. 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"

Первое, на что нужно обратить внимание, - это номер версии, из-за которой все зависит от того, от чего все зависит. Если он много используется, я извлекаю версию в переменную. Во-вторых, аннотация intransitive(). В то время как я могу иногда уйти без него, я считаю, что явное держит дела и мои волосы на месте.

Я склонен придерживаться интерфейсных дружественных пакетов, таких как реакция и angular. Некоторые из новых библиотек реагирования имеют десятки транзитивных зависимостей и попытки их использования будут болезненными. Я избегаю этих = p