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

Question

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

Вопрос

Ммм? Что делать, если я просто делал то, что раньше делал, но создавал зависимости без приложения в какой-то гигантский файл или набор файлов, а затем загружал их в сборку? У меня есть доказательство концепции из онлайн, и я получил его работу (я думаю, это был 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, поэтому, хотя она не идеальна, это всего лишь один трубопровод разлома вместо двух.

Несмотря на это, они могут быть болезненными. У меня около 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(). В то время как я могу иногда уйти без него, я считаю, что явное держит все, что работает, и мои волосы на месте.

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