大量的 JavaScript 包管理解决方案让我们既受祝福又受诅咒,所有这些解决方案都有各自的优点。出于与这里无关的原因,我已选择 npm 作为我的主要解决方案。但是,在其他系统(例如 bower 和 component)上有太多好的代码可以忽略这些解决方案。所以,我希望建立一个环境,我可以使用 browserify 从 npm 和 bower 加载包(我们将保存组件以用于另一个问题)。
到目前为止,我想出的最好的方法是设置我的 package.json
与 postinstall
运行 bower install
的脚本:
{
... configuration ...
"scripts": {
"postinstall": "bower install"
}
}
这会在安装一级依赖(即strait bower依赖和strait npm依赖)时构建正确的目录结构:
- MyMixedComponent
- main.js
- package.json
- node_modules
- npmDependency
- bower_components
- bowerComponent
使用 debowerify 构建良好在 browserify 上转换,browserify -t debowerify
但是,当我想在另一个项目中从 npm 安装 MyMixedComponent 时,npm install MyMixedComponent
, 目录结构是按照你对 npm 的期望构建的:
- MyNewProject
- main.js
- package.json
- node_modules
- MyMixedComponent
- main.js
- package.json
- node_modules
- npmDependency
- bower_components
- bowerComponent
因为 bower 是一个扁平的依赖树,这在尝试使用 browserify 和 debowerify 构建时当然不起作用。实际需要的是这样的:
- MyNewProject
- main.js
- package.json
- node_modules
- MyMixedComponent
- main.js
- package.json
- node_modules
- npmDependency
- bower_components
- bowerComponent
或者可以修改 debowerify 以识别多个 bower 目录,但这会破坏 bower 的可爱特性,即它是一棵扁平树,这对于前端依赖项来说要好得多。关于这如何工作的任何想法,或者我应该祈祷我们有朝一日就依赖管理达成一致吗?
最佳答案
在同一个代码库中拥有多个 bower_components 的想法存在引入某些特定框架的重复项的风险。
尝试沿着这条路走:
- 将混合(npm 和 bower)包安装到我当前的包中时,
- 照常安装 npm(嵌套),
- 对于混合包
bower install
中的每个 bower-component 到当前包的根目录 - 安interactive npm postinstall script , 可以改变当前包的 bower.json
- 并警告用户安装 bower,因为 bower.json 现在已使用其他 npm/bower 混合包中的组件进行更新
关于node.js - 使用 browserify 使 bower 与 npm 一起工作,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/22820543/