我们在 JavaScript 包管理方面有很多选择,这既是福音也是诅咒。每个方案都有其优点。出于某些原因,我选择了 npm 作为我的主要解决方案。然而,其他系统(如 bower 和 component)中也有很多好的代码,我们不能忽视这些方案。因此,我希望设置一个环境,在这个环境中,我可以使用 browserify 从 npm 和 bower 中加载包(component 的问题留待另一篇文章讨论)。
目前我想到的最好的方法是,在
这将在安装一级依赖项(即直接的Bower依赖项和直接的npm依赖项)时构建正确的目录结构:
使用debowerify转换器在browserify中编译正常,
目前我想到的最好的方法是,在
package.json
中设置一个 postinstall
脚本来运行 bower install
命令。{
... configuration ...
"scripts": {
"postinstall": "bower install"
}
}
这将在安装一级依赖项(即直接的Bower依赖项和直接的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 的优秀特性,即它是一个扁平的树形结构,这对于前端依赖项来说更好。你有什么想法吗?还是我只能祈祷我们总有一天会在依赖管理上达成共识?
napa username/repo-with-bower; cd node_modules/repo-with-bower; bower install;
。 - Brian Peacockgrunt
自动化呢? - rollingBalls