title: In a ScalaJs sbt build, is there any advantage to use webjars instead of npm or bower with 'Provided'?
body: <p>When I first discovered webJars a few months ago I was super-skeptical that it would be be a viable way means of handling client-side dependencies given the enormous complexity of some of these builds/buildsystems, and given the frequency that <code>js</code> files are published. The second concern was of course not well-founded but I feel vindicated on the first after spending almost 36 hours now trying in vain to get about 10 <code>scss/css/less</code>-type webJars and 8 JS webJars to live under one <code>jsDependencies</code> roof.</p>
  
  <p>What I found as that by the time you reach JS dependency 3, 4, or 5,you start getting into a ridiculous timekill loop:</p>
  
  <h1>1. "Oh nos! fastOptJS failed because there was some random file that was also named the same as a dependency in the webjar!"</h1>
  
  <pre><code>[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
  </code></pre>
  
  <h1>2. I know what to do! I'll add a version to the defined js!</h1>
  
  <pre><code>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"
  </code></pre>
  
  <h1>3. "Oh no! fastOptJS failed!"</h1>
  
  <pre><code>[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
  </code></pre>
  
  <p>gg boys.</p>
  
  <p>This goes over and over and around and around, and then I have to start doing </p>
  
  <pre><code>lazy val         bs_sidebar   = ( "org.webjars"               %    "bootstrap-sidebar"              % version.bs_sidebar intransitive())  / "js/sidebar.js" dependsOn(s"bootstrap.js",  s"bootstrap.min.js")
  </code></pre>
  
  <p>and now I'm not really even using the webjar, but it has a <strong>js</strong>dependency named X and I cannot change that...</p>
  
  <h1>Question</h1>
  
  <p>Hmmm? What if I just did what I used to do but build the dependencies without the app into some gigantic file, or set of files, and then feed that into the build? I have a proof of concept from online and I got it work (I think it was <a href="https://github.com/wav/material-ui-scalajs-react/blob/master/src/main/scala/wav/web/muiwrapper/package.scala">https://github.com/wav/material-ui-scalajs-react/blob/master/src/main/scala/wav/web/muiwrapper/package.scala</a> ) which almost worked, and gave me the idea.</p>
  
  <p>I know <code>npm</code> works a lot better than <code>sbt,</code> and I can still get it into my package... what's the downside, and <strong>am I missing something about sbt</strong>?</p>