答案1
答案2
有一个这里提出了热情的案例,最后总结如下:
所有软件包管理器都做着相对相同的事情。移动文件。根据它在这方面的表现来选择软件包管理器。所有构建工具都做着相对相同的事情。转换文件。根据它在这方面的表现来选择构建工具。如果你现在不使用 npm 仅仅是因为有人告诉你它不适合客户端。打他们一巴掌,说“npm 所有东西。”
我自己的看法是:客户端和节点通常可以使用通用代码。因此一天客户端和节点项目占用同一个存储库是明智的。无论是哪个存储库,它(理想情况下)都会获得临界质量并取代所有其他客户端和节点存储库。既然 npm 已经如此成熟,为什么它不应该成为那个存储库呢?
答案3
NPM 是专门为管理在 Node.js(服务器端)下运行的 JavaScript 包而设计的。现在,npm 公共存储库原始设计出现了一些问题(例如扁平命名空间问题),并且出现了替代的 JavaScript 包管理器。
直到最近,旨在解决所有这些 JavaScript 服务器/端客户端/端包依赖问题的是component
使用 GitHub 存储库及其命名空间的包管理器。
这篇文章一开始是这样的:http://tjholowaychuk.tumblr.com/post/27984551477/components
目前有 ~2500 个软件包组件公共存储库。
此处提供了与其他 JavaScript 包管理器的简短比较:https://github.com/component/guide/blob/master/component/vs.md
答案4
NPM 最近发布了一篇有关此问题的博客文章:http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging
“npm 仅适用于服务器端 JavaScript!”
这也不正确。你的包可以包含任何东西,无论是 ES6、客户端 JS,还是 HTML 和 CSS。这些东西自然会与 JavaScript 一起出现,所以把它们放进去。
...
如果与 JavaScript 相关,请将其托管在 npm 中。一旦它们可用,请使用生态系统在全球注册中心内创建“微型注册中心”,并完成自定义搜索索引和显示特性。
是的。将客户端 JavaScript 内容放入 NPM 中是完全没问题的,而且他们会改进对此的支持。