使用 Webpack 模块化 Angular 应用程序（2）

look_w

创建依赖关系因为我们在模块化源代码时已建立了一个基准代码（codebase），所以几乎每个源文件都需要进行某种程度的修改。我们不希望我们的更改带来负面影响，所以我们建立了一种模式：定义                Angular 模块的文件将加载与该模块关联的所有源文件；然后每个源文件需要该父模块。甚至在只需要一个工厂或指令时，也要先定义它的关联模块。此方法很有效，因为每个                Angular 模块已分离到自己的目录中，指令、服务等都放入该目录内的子目录下。
以下是我们在模块定义文件中遵循的一般模式：

var angular = require('angular'); var load = require.context('./', true, /\.js$/); load.keys().forEach(load); module.exports = angular.module('pi.utils', []).name;

此模式使用 webpack 的   API                构建一个要加载为模块的文件列表。然后，我们可以保留该模块所维护的一个最新的资源列表，而无需手动维护一个 require 列表。我们随后从该模块导出了 Angular                模块名称。
在我们的工厂、指令和控制器文件中，我们遵循的模式是要求使用定义了 Angular 模块的文件，该模式会导出 Angular 模块的名称：

var angular = require('angular'); angular.module(require('../utils')).factory('logger', function () {});

测试应用程序我们已有一套必要的测试，可确保在模块化源代码后应用程序能继续运行。最初，我们使用了与我们的仪表板类似的东西，我们在其中手动维护所包含脚本的列表。我们需要跟踪记录两个位置的脚本列表。
我们继续使用   作为测试运行器，使用                  作为代码覆盖工具，但我们需要执行一些额外的配置才能像之前一样运行测试并生成有意义的覆盖范围。
返回到入口点我们的入口点需要我们的应用程序并拉入我们的所有测试文件。因为该应用程序需要它的所有依赖项（而且这些依赖项又需要自己的依赖项），所以我们最终获得了所有需要的资源。而且与我们在源代码模块中使用的模式一样，我们使用了                    require.context，使用模式                /\.spec\.js$/（您的测试文件不一定有类似这样的模式）来加载所有测试文件：

require('../../app/scripts/app'); var load = require.context('./', true, /\.spec\.js$/); load.keys().forEach(load);

更新测试配置在我们的 Karma 配置中，我们通过指定我们创建的入口文件的路径，更新了要包含在套件中的文件列表。我们还定义了 webpack                作为测试套件的预处理器，并包含了我们用于开发应用程序的通用 webpack 配置：

var webpackConfig = require('../webpack.config'); module.exports = function (config) {   return {     // ... webpack related configuration ...     webpack: webpackConfig,     files: ['test/spec/suite.js'],     preprocessors: {       'test/spec/suite.js': ['webpack']     }     // ... end webpack related configuration ...   } }

要让此代码正常运行，您需要安装 karma-webpack 插件。要安装该插件，请运行：

npm install --save-dev karma-webpack

如果我们的测试现在正在运行，各项功能或许有效。但是，代码覆盖范围肯定会被破坏。所以我们添加了                    istanbul-instrumenter-loader：

npm install --save-dev istanbul-instrumenter-loader

并在 webpack 配置中，将 istanbul-instrumenter 添加到模块列表 postloaders 中：

var webpackConfig = require('../webpack.config'); // Use istanbul-instrumenter to make sure we're covering individual files // instead of bundles webpackConfig.module.postLoaders = webpackConfig.module.postLoaders || []; webpackConfig.module.postLoaders.push({   test: /\.js$/,   // Exclude the things we don't need to report coverage on   exclude: /(test|node_modules|bower_components)\//,   loader: 'istanbul-instrumenter' });

其他考虑因素（依赖注入）Angular 的一个有用的特性是 （Dependency                Injection，DI）。但在您模块化脚本后，依赖注入就会失去部分光彩。通过模块化，除了可通过依赖注入完成的工作外，您还可以完成更多工作。而且依赖注入也存在着陷阱：

• 您可能会在代码中搜索，查找在何处声明了 myCoolFactory。
• 假设您意外地创建了两个同名的工厂。该应用程序可能开始出现一些奇怪的行为，因为应用程序中的所有依赖关系都存储在一个全局哈希表中，而且一个工厂被另一个工厂覆盖——这种情形下很不容易调试。
• 如果使用依赖注入，您需要 （repeat yourself），或者添加一个新构建步骤，以防您的代码在最小化过程中被损坏，注入的依赖项不再起作用。

很难完全抛弃依赖注入而单纯使用 CommonJS 或 AMD 依赖关系。此外，这可能对“Angular                方式”不利，您最终可能得到一个完全无用的基准代码。但是，如果您想充分利用所完成的工作来模块化您的应用程序，则需要考虑避开依赖注入。