我们都受到了大量的JavaScript包管理解决方案的祝福和诅咒，所有这些都有各自的优点。由于这里无关紧要的原因，我已经确定了我的主要解决方案。但是，在其他系统（例如凉亭和组件）上有太多好的代码可以忽略这些解决方案。所以，我希望建立一个环境，我可以使用browserify从npm和bower加载包（我们将为另一个问题保存组件）。
到目前为止，我提出的最好的方法是使用运行package.json的{{1}}脚本设置postinstall：
bower install在安装第一级依赖项（即strait bower依赖项和strait npm依赖项）时构建正确的目录结构：
{
... configuration ...
"scripts": {
"postinstall": "bower install"
}
}
使用browserify上的debowerify转换，- MyMixedComponent
- main.js
- package.json
- node_modules
- npmDependency
- bower_components
- bowerComponent
构建正常但是，当我想在另一个项目browserify -t debowerify中从npm安装MyMixedComponent时，目录结构就像你一样构建了期待从npm：
npm install MyMixedComponent由于bower是一个平面依赖树，当使用browserify和debowerify进行构建时，这当然不起作用。实际需要的是这样的：
- MyNewProject
- main.js
- package.json
- node_modules
- MyMixedComponent
- main.js
- package.json
- node_modules
- npmDependency
- bower_components
- bowerComponent
或者可以修改debowerify以识别多个凉亭目录，但这会破坏凉亭的可爱特性，即它是一棵扁平树，这对于前端依赖性来说要好得多。关于这可能如何工作的任何想法，或者我应该祈祷我们总有一天会同意依赖管理？
答案 0 :(得分：1)
在同一代码库中拥有多个bower_components的想法存在引入某些特定框架的重复的风险。
尝试走下去：
bower install转换为当前包的根