在ScalaJs sbt构建中,使用webjars而不是npm或bower与'提供'是否有任何优势?

tac*_*cos 11 sbt node.js scala.js sbt-web

几个月前,当我第一次发现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
Run Code Online (Sandbox Code Playgroud)

我知道该怎么做!我将为定义的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"
Run Code Online (Sandbox Code Playgroud)

"哦,不!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
Run Code Online (Sandbox Code Playgroud)

gg男孩.

这种情况一遍又一遍,然后我必须开始做

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

现在我甚至不是真的使用webjar,但它有一个名为X 的js依赖,我不能改变它......

嗯?如果我只是做了我以前做的事情但是在没有应用程序的情况下将依赖关系构建到一些巨大的文件或文件集中,然后将其提供给构建中,该怎么办?我有一个在线概念证明,我得到了它(我认为它是https://github.com/wav/material-ui-scalajs-react/blob/master/src/main/scala/wav/web/ muiwrapper/package.scala)几乎可以工作,并给了我这个想法.

我知道npm工作比sbt,我好多了,我仍然可以把它放到我的包里......有什么缺点,我错过了什么关于sbt

sjr*_*jrd 12

我同意你的看法.一旦应用程序开始对JavaScript库具有非平凡的依赖性,jsDependencies就无法扩展.这主要是因为WebJars缺少关键功能(就像传递依赖性一样),但也因为jsDependencies它不是一种可扩展的机制.

随着时间的推移,用户已经要求越来越多的功能jsDependencies,因为他们希望将其用作真正的应用程序规模(无论这意味着)依赖机制.因此,我们一直在修补越来越多的功能/黑客jsDependencies.结果不是世界上最漂亮的东西,它肯定有缺点.

我实际上鼓励使用npm来解决你的依赖关系,特别是如果你熟悉它并知道如何将它集成到你的工作流程中.

  • 可以预期,大多数复杂的构建最终都将比`jsDependencies`更具原则性。`npmDependencies`绝对是一种选择。 (2认同)