Bower培训

第一章 Bower简介

1.1 起源

Bower是@fat和@maccman在Twitter上创建的，最初是在2012年作为Twitter开源项目的一部分发布的。自从它发布以来，许多人都做出了贡献。Bower是一整个团队努力的结果，并不断的在完善。

1.2 现状

Bower 是 twitter 推出的一款包管理工具，基于nodejs的模块化思想，把功能分散到各个模块中，让模块和模块之间存在联系，通过 Bower 来管理模块间的这种联系。

Bower 特点：

宽松的规范能很好地直接应用在很多已经存在的项目中，所有人都能通过简单地添加一个bower.json以及补充相关信息，不需要修改代码和目录结构，就马上开始使用注册发布自己的模块，因此bower本身并不提供一套构建工具，它充当的基本上是一个静态资源的共享平台。

功能：

  • Bower可以管理很多组件包括 HTML , CSS , JavaScript , 字体甚至是图片文件， Bower并不是用来连结它们或压缩代码的，它只是用来根据你的需要或者代码的依赖来安装正确版本的包。
  • Bower通过从各个地方抓取和安装包来进行工作，处理你所寻找的正在捕获，查找，下载和保存的资料。
  • Bower在清单文件 bower.json 里对这些包进行跟踪，当然如何使用这些包取决于你自己。Bower会提供挂钩使你在你 的工具和工作过程中更方便的使用这些包。
  • Bower对前端进行了优化，如果多个包依赖于一个包，比如JQuery，Bower就会只下载一次JQuery。

1.3 发展

Bower 是 Twitter 上的开源项目的一部分，它的团队通过将 Bower 放到 GitHub 上来征集使用者的意见和建议，不断完善 Bower 的功能，使 Bower 更方便，能更好的与其他工具一起使用。

第二章 bower安装使用

2.1 bower安装

由于bower是基于nodeJS的前端包管理工具，并且需要远程git仓库获得资源，故而bower的安装应当具备：

  • node
  • npm
  • git

Bower的安装：

npm install bower -g #-g表示全局安装

安装后可以通过下面两行代码中任意一个来查看是否安装成功：


bower help
bower --version

2.2 bower使用

- bower init

bower init

项目目录下，使用bower init创建bower.json文件，该文件是项目的配置文件，举例：

- bower install

bower install [<options>]
bower install <endpoint> [<endpoint> ..] [<options>]

这个指令将递归安装项目所需依赖，这些依赖包括：

  • bower.json里项目相关的依赖。
  • 所有没有在bower.json中指定但存在于bower组件中的外部依赖。
  • 任何通过 endpoint 参数添加的依赖。

其中endpoint可以是：

等等

option指的是：

  • -F/--force-latest 强制安装最新版本的package
  • --p/--production 不要安装项目依赖的devDependencies
  • -S/--save 将下载的安装包安装到bower.json的dependencies中
  • -D/--save-dev 将下载的安装包安装到bower.json的devDependencies中
  • -E/--save-exact 配置下载一个制定版本的package，而不是项目中必须依赖的版本
  • 如果不使用参数，则只安装包到bower_components目录，不修改bower.json文件。

Endpoints可以有多种形式：

<package>
<package>#<version>
<name>=<package>#<version>

<package>是一个包URL，物理位置或注册表名称 <version>是一个有效的范围，提交，分支等 <name> 是它应该在本地的名字。

  • bower list

bower list可以查看当前目录下已安装的package以及可能的版本更新信息

  • bower lookup

查看pkg的url；

  • bower update
bower update <pkg>

将bower升级到最新的版本

  • bower uninstall
bower uninstall <pkg>

删除特定的 package；

  • bower cache
bower cache list
bower cache clean

2.3配置bower下载package的安装路径

创建.bowerrc文件:

{
"directory": "app/dist"
}

配置这个选项，会将bower下载的安装包下载到app/dist目录下取代默认的bower_components路径

第三章 bower同技术类比

  • Bower

bower 的缺点比较明显，最大的问题就是缺乏统一的构建机制。但有意思的是 Google 的 Polymer 选择了 bower 作为包管理器，因为 Polymer 是建立在两个还没在浏览器里普遍实现的东西上的：HTML Import 和 SPDY。HTML Import 让你可以把 HTML, CSS, JS 写在同一个 HTML 文件里作为一个组件或是模块，然后通过一行代码引入：

<link rel="import" href="my-component.html">

同时，在一个组件里也可以引入其他的组件，也可以直接引用远程服务器上的组件。某种程度上 HTML import 可以取代现在的组件模块机制。而 SPDY 是下一代的 http 协议，可以让浏览器只用一个服务器连接传输多个文件。换句话说即使你页面里有很多个 HTML import 也不会因为多次请求导致页面加载缓慢。在这两个东西存在的理想情况下，前端项目是完全可以不需要构建过程的。这是 Bower 长远来看的一个意义，但现阶段对大多数开发者而言，构建依然是一个必不可少的步骤。

  • Component

缺点：

  • 每一个 component 都必须要在 component.json 中手动列出所有文件，每次更改项目结构或是重命名文件都很麻烦，我还为此写了个 grunt 插件专门自动做这个事情。
  • component 只有一个 wiki page 列表，没有一个可搜索的中央数据库，模块的可发现度比较低。同时，github 仓库的星数是唯一的模块质量指标，而 npm 则有下载统计和被依赖数量这些更实在的数据。
  • 模块发现度低带来的另一个问题就是不同作者的模块之间很少出现公用的依赖。虽然 Component 的依赖是扁平的，在实际使用别人的模块的时候依然会出现重复（同样的问题不同的实现），这就导致很多人只是把 Component 当个工具而不是平台用。
  • npm + Browserify

npm 其实是一个非常好的前端包管理方案，最主要的就是依靠 Browserify 这个神器。Browserify 最大的意义不是让你能在 npm 上发布前端的静态资源，而是实现前后端的代码共享。npm上有很多包是前后端通用的，常用的库如 jquery backbone 等，只要你想得到的基本上都有 npm 版本。需要什么直接 npm install 就可以用在浏览器端的项目里了，Component 和 Bower 在这方面跟 npm 完全没有可比性，spm 就更不提了。

开发流程上来说也极其省心，项目用 CommonJS 写，不需要任何配置，给一个入口文件就行！还有一个官方工具 watchify，一行命令跑起，保存文件自动构建，连 grunt gulp 都不需要。

缺点: 就是 npm 的树状依赖结构可能导致重复的模块和代码量的臃肿，需要跑一次 npm dedupe 来尽量压平依赖树。当然，实际情况中前端模块出现依赖同一模块的不兼容版本还是很少见的。

参考文档

results matching ""

    No results matching ""