W kompilacji ScalaJs sbt, czy jest jakaś korzyść używać webjars zamiast npm lub altana z "Provided"?

Question

Kiedy po raz pierwszy odkryłem webJars kilka miesięcy temu, byłem super-sceptyczny, że byłby to opłacalny sposób na obsługę zależności po stronie klienta, biorąc pod uwagę ogromną złożoność niektórych z tych buildów/systemów konstrukcyjnych, i biorąc pod uwagę częstotliwość, z jaką pliki js są publikowane. Druga troska była oczywiście nieuzasadniona, ale czuję się usprawiedliwiona po tym, jak spędziłem prawie 36 godzin, próbując bezskutecznie uzyskać około 10 scss/css/less -tyświatów sieci web i 8 JS sieciowych pod jednym dachem jsDependencies.

Co znalazłem jako że do czasu można dotrzeć JS zależność 3, 4 lub 5, zaczną się w śmiesznej pętli timekill:

1. „Och nos fastOptJS powiodło się, ponieważ nie było pewne losowy plik! to też było nazywane tak samo jak zależność w 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. Wiem, co robić! Dodam wersję do zdefiniowanego 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. "O nie! FastOptJS nie powiodło się!"

[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.

idzie to w kółko i w kółko, a potem muszę zacząć robić

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

i teraz nie jestem nawet za pomocą webjar, ale ma js zależność nazwie X i nie mogę tego zmienić ...

Pytanie

Hmmm? Co zrobić, jeśli zrobiłem to, co robiłem, ale budowałem zależności bez aplikacji w jakiś gigantyczny plik lub zbiór plików, a następnie dodawałem je do kompilacji? Mam proof of concept z Internetu i dostałem go (myślę, że to był https://github.com/wav/material-ui-scalajs-react/blob/master/src/main/scala/wav/web/muiwrapper/package.scala), który prawie działał i dał mi pomysł.

wiem npm działa dużo lepiej niż sbt, i nadal nie mogę dostać się do mojego pakietu ... co jest wadą, a jestem brakuje czegoś o SBT?

Answer 1

Zgadzam się z Państwem. Gdy aplikacja zacznie mieć nietrywialne zależności w bibliotekach JavaScript, skala jsDependencies nie jest skalowana. Dzieje się tak głównie dlatego, że WebJars brakuje krytycznych funkcji (podobnie jak przejściowe zależności), ale także dlatego, że jsDependencies nie był mechanizmem zaprojektowanym do skalowania.

W miarę upływu czasu użytkownicy pytali o coraz więcej funkcji jsDependencies, ponieważ chcą używać go jako mechanizmu prawdziwej skali aplikacji (cokolwiek to znaczy). W rezultacie łataliśmy coraz więcej funkcji/hacków pod numerem jsDependencies. Rezultat nie jest najładniejszą rzeczą na świecie i ma zdecydowanie braki.

Właściwie zachęcam do korzystania z npm w celu rozwiązania twoich zależności, szczególnie jeśli jesteś zaznajomiony z nim i wiesz, jak zintegrować go z przepływem pracy.

Answer 2

Główną zaletą korzystania z słoików internetowych, moim zdaniem, nie jest stosowanie npm.Ponadto przechodzą one przez zwykły proces rozwiązywania/pobierania maven, więc chociaż nie jest idealny, jest to tylko jeden potok przerwania zamiast dwóch.

Bez względu na to, mogą być bolesne. Mam około 30 zależności w mojej aplikacji scala.js i są one w większości zarządzane za pomocą słoików internetowych. Zauważyłem, że generalnie uzyskuję lepsze wyniki przy użyciu npm webjars vs. altówki webjars, i jest głupotą, aby spróbować polegać na przejściach przechodzących przez słoik internetowy.

My jsDependencies wydają się wyglądać tak:

("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" 

Pierwszą rzeczą, aby pamiętać, jest numer wersji zniekształcone na zasadzie wszystko, że kiedykolwiek zostanie zależało na. Jeśli jest dużo używany, wydaję wersję na zmienną. Drugą rzeczą jest adnotacja intransitive(). Chociaż czasami mogę uciec bez tego, stwierdzam, że wyraźne zachowanie działa i moje włosy są na miejscu.

Mam tendencję do trzymania się przyjaznych pakietów front-end, takich jak reagowanie i kątowe. Niektóre z nowych bibliotek reagowania mają dziesiątki przechodnich zależności i próba ich użycia będzie bolesna. Unikam ich = p