В сборке 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