在前端项目的源码管理中，依赖的管理是相当重要的一部分。它可以使代码在项目的各个开发机器、持续集成服务器上快速地搭建、运行、布，而不需要确认依赖版本等额外的工作。早期没有依赖管理软件时，项目的依赖放：代码库中——每次更新依赖的时候，均需向项目的代码库提交一个新的版本，这导致项目的代码库越来越大，对新成员越来越不友好。在有了依赖管理之后，我们只要执行安装命令，如npm install,再执行运行服务就可以进行开发。
AMD、CommonJS和UMD,它们是三种不同的JavaScript模块化方案。这些模块化方案，在一定程度上影响着项目的依赖管理。
AMD
AMD(Asynchronous Module Definition)即异步模块定义，其典型的表现形式是通构建好的JavaScript库文件，直接在浏览器中引入依赖，典型的框架有jQuery。为了引用试。这些采用AMD方式的库，我们还需要使用诸如require.jsjs这样的AMD管理库来管理依赖。如果这些AMD库是在浏览器上通过script直接引入并运行的，那么它们就可以使用ower来进行管理。
AMD方式：通过Bower进行管理。谈到AMD库的管理，一般会有两种方式，一种是直接下载对应的库，另一种是可以由后来的Bower进行管理。过去前端的基础设施不完善，没有统一的软件包中心，开发者需要在搜索引擎或者GitHub上找到代码库，然后下载解压，再从中复制出代码文件、资源文件等。在有了Bower之后，开发者只需要在bowerjson文件中添加所需要的依赖，就可以由Bower自动下载这个依赖的相关内容——该库打包到bower的服务器上（Bower是一个包管理工具）,它可以管理包含HTML、CSS、JavaScript、字体甚至图像文件的组件。Bower的工作原理是，从各个地方获取安装包，并搜索、查找、下载和保存正在寻找的内容。因此，Bower在过去的某段时间里非常流行。值得注意的是，由于现今的大部分新的前端应用都是通过CommonJS及AMD的方式来引入依赖的，所以Bower的使用场景越来越少。
CommonJS
CommonJS最初被用于在非浏览器端使用JavaScript来管理模块，比如使用Nod来开发服务器应用。设计的目的是避免模块定义全局对象，即JavaScript的作用域问题。在CommonJS库里，每个文件就是一个模块。开始时，CommonJS在Node.js服务端运行随着Browserify和webpack能将这些CommonJS编译为浏览器能运行的JavaScript,走来越多的前端框架直接使用CommonJS来管理模块。
CommonJS方式：通过NPM/Yarn管理。由于CommonJS早先是用在Node.js项目上的，所以其包管理工具NPM也与CommonJS有了更多的交集。NPM(Node Package Manager,Node包管理器）是JavaScript世界的包管理工具，并且是Node.js平台的默认包管理工具。开发人员通过NPM可以安装、共享、分发代码，并管理项目依赖关系。此外，这些包会分发到NPM的官方网站npmjs.org上，以便对NPM包进行更好的管理。除了NPM,还可以使用Yarn来管理依赖。Yarn是由Facebook推出的一款新的Javascript包管理工具，其特色是Yarn会缓存它下载的每个包，因此不用重复下载就可以加快安装速度。随着Yarn提出缓存包的功能，NPM也提供了相似的功能。目前主流的前端应用框架（React、Angular、Vue)支持并采用的方式主要以编译构建为主，大都采用NPM+CommonJS的形式来管理依赖。
UMD
随着AMD和CommonJS的流行，又产生了UMD(Universal Module Definition,用模块定义）,它是AMD和CommonJS的揉合，它会判断是否是Node.js的模块。常见的代码中的opeofexports--object就是用于判断NodeJs中的模块（Exports)是否存在。如果不存，则使用AMD的方式来加载模块。