In una versione sbt di ScalaJs, c'è qualche vantaggio nell'usare webjars invece di npm o bower con 'Provided'?

Question

Quando ho scoperto WebJars alcuni mesi fa ero super-scettico sul fatto che sarebbe stato un modo valido per gestire le dipendenze lato client data l'enorme complessità di alcuni di questi build/buildsystems, e data la frequenza dei file js sono pubblicati La seconda preoccupazione ovviamente non è stata fondata, ma mi sento confermata per la prima volta dopo aver trascorso quasi 36 ore cercando invano di ottenere circa 10 scss/css/less -type webJars e 8 JS webJars per vivere sotto un tetto jsDependencies.

Quello che ho trovato, come che per il momento si raggiunge JS dipendenza 3, 4, o 5, è iniziare a ricevere in un ciclo timekill ridicolo:

1. "Oh nos fastOptJS fallito perché c'era un po 'di file casuale! anche questo è stato identificato come una dipendenza nel 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. So cosa fare! Aggiungerò una versione al js definito!

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. "Oh no! FastOptJS non riuscito!"

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

Questo va più e più e intorno e intorno, e poi devo iniziare a fare

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

e ora io non sono davvero anche utilizzando il webjar, ma ha un js dipendenza chiamato X e non posso cambiare la situazione ...

domanda

Hmmm? Cosa succede se ho appena fatto ciò che ero solito fare, ma costruire le dipendenze senza l'app in un file gigantesco, o un insieme di file, e poi inserirli nella compilazione? Ho una prova di concetto da online e l'ho fatta funzionare (penso che fosse https://github.com/wav/material-ui-scalajs-react/blob/master/src/main/scala/wav/web/muiwrapper/package.scala) che ha quasi funzionato, e mi ha dato l'idea.

So npm funziona molto meglio di sbt, e posso ancora ottenere nel mio pacchetto ... qual è il rovescio della medaglia, e mi sto perdendo qualcosa su sbt?

Answer 1

Sono d'accordo con te. Quando un'applicazione inizia ad avere dipendenze non banali nelle librerie JavaScript, jsDependencies non viene ridimensionata. Ciò è dovuto principalmente al fatto che a WebJars mancano funzionalità critiche (proprio come dipendenze transitive), ma anche perché jsDependencies non era un meccanismo progettato per scalare.

Con il passare del tempo, gli utenti hanno richiesto un numero sempre maggiore di funzioni di jsDependencies, perché vogliono utilizzarlo come meccanismo di dipendenza vero e proprio (in qualunque modo ciò significhi). Di conseguenza, abbiamo applicato patch a un numero sempre maggiore di funzioni/hack in cima a jsDependencies. Il risultato non è la cosa più bella del mondo e ha sicuramente dei difetti.

In realtà vorrei incoraggiare l'uso di npm per risolvere le dipendenze, soprattutto se si ha familiarità con esso e sappiamo come integrarlo nel flusso di lavoro.

Answer 2

Il vantaggio principale dell'utilizzo di web jars, a mio parere, non è dover utilizzare npm.Inoltre, seguono il solito processo di risoluzione/download del software, quindi mentre non è perfetto, è solo una pipeline di interruzione invece di due.

Indipendentemente da ciò, possono essere dolorosi. Ho circa 30 dipendenze nella mia app scala.js e sono principalmente gestite con web jars. Ho scoperto che, in generale, ottengo risultati migliori usando webjars di npm e webjars di bower, ed è una follia tentare di fare affidamento sulle dipendenze transitive di web jar.

mio jsDependencies tendono ad assomigliare a questo:

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

La prima cosa da notare è il numero di versione storpiato su praticamente tutto ciò che mai viene dipendeva. Se viene usato molto, estrao la versione in una variabile. La seconda cosa è l'annotazione intransitive(). Anche se a volte riesco a cavarmela senza di essa, trovo che essere espliciti mantenga le cose funzionanti e i miei capelli al loro posto.

Io tendo ad attenermi a pacchetti amici front-end come reagire e angolare. Alcune delle nuove librerie di reagenti hanno dozzine di dipendenze transitive e il tentativo di usarle sarebbe doloroso. Evito quelli = p