导入现有的JavaScript项目成咕噜/早午餐项目

Question

我看着保罗爱尔兰的谈话，宣布约曼（www.yeoman.io），我上运行的持续构建环境的概念，大呼过瘾。没有满足于等待Yeoman邀请，我尝试了Grunt和Brunch。两者都可以轻松安装，我可以用最少的努力启动并运行新项目。

我不明白如何将现有项目迁移到任一平台。我的项目使用单个命名空间，并为模块使用两个约定（一个用于实例化另一个实用程序），每个模块都封装在导出到实例或名称空间的自执行匿名函数中。

我至少有200个模块和许多更简单，辅助函数出口的命名空间;因此使用控制台在grunt/brunch项目中创建这些控制台并单独手动导入每个模块并不十分有效。此外，我使用至少15种不同的第三方JavaScript工具。这是我不清楚如何将这些。

什么是采取一个大的，现有的项目，并将其与重构和支持的任意第三方工具的最低金额迁移到格朗特/早午餐最有效的方法是什么？

更新：这两个，我发现早午餐更容易应付。如果您使用库存“框架”（即“模板” - 从命令行{在您想要更改的文件夹中执行}执行“brunch new [project_name] --skeleton git：//github.com/brunch /simple-js-skeleton.git“）为纯JS，你会得到一个新的文件夹结构，它实际上是相当敏感的。您在文件编辑时（当您运行“早午餐手表”时）会自动为您重新编译“应用程序”（您自己的代码）或“供应商”（第三方）文件夹。

这很好，除了。根据文档，您可以控制订单供应商脚本从Brunch config.coffee文件（JSON文本文件）编译和连接在一起。 对此文件所做的更改似乎没有效果，因此您最终会遇到期待其他插件的插件中的第三方争用条件。

此外，当你把你自己的代码到你得到一个自动编译，实时，随你编辑的版本代码的自动创建的“应用程序”文件夹;但无法访问。 Brunch混淆了窗口对象，所以我对window.myNameSpace的初始名称空间声明失败，并且对命名空间的所有后续库调用也失败。这与Brunch的模块系统有关，为此我找不到任何文档。

我解决了这个通过将我的名字空间类在“供应商”的文件夹，这保证它连接到窗口对象;然而，现在有一个竞争条件：我的命名空间并不总是适用于我所有的模块。

现在的问题是这样的：

一旦复制了所有内部和外部库的进入早午餐项目，你如何配置应用程序加载它们在一个健全的订单？

Answer 1

这是一个作品，但我终于明白了。当我开始使用Brunch时，如何进行第一步并不明显：导入我的目录结构。我花了几道文件结束，之前很明显：

1. 执行brunch new MyAppName -s https://github.com/damassi/Javascript-App-Skeleton，这将产生一个骨架文件夹结构和config.coffee文件
2. 对于我来说，在这个结构中的唯一相关的文件夹是'app'（用于CSS，JS和HTML的原始src内容），'public'（编译内容的目的地以及为NodeJS服务器提供服务的位置）和'vendor'（用于第三方文件的位置）。
3. 早在创建的目录结构的根与此内容config.coffee文件：files: javascripts: defaultExtension: 'js' joinTo: 'javascripts/app.js': /^app/ 'javascripts/vendor.js': /^vendor/ order: before: [ 'vendor/scripts/console-helper.js', 'vendor/scripts/jquery-1.7.1.min.js' ]
4. 将这个对象的“joinTo”属性困惑我，直到我意识到，“JavaScript的”实际上只是'面具客户端代码“，并且'apps.js'实际上是递归地'调用'在文件夹中'获取所有* .js文件'的应用程序'。
5. 一旦明确，您需要做的就是将您的内容放入'app'中。我将我的* .html和图像文件放入“assets”子文件夹中，并将所有JavaScript内容放入lib中。
6. 此时，您可以运行brunch build和brunch watch，并且您的项目已启动并正在运行，在您进行更改时实时编译，在浏览器中实时重新加载。

虽然Brunch在使用第6步时比Grunt更易于使用，但对于我来说失败的是Brunch中编译的本质。每个JavaScript文件都包装在CommonJS模块中，模块名称基于相对路径和文件名（'lib/core/ajax'等）。 CommonJS哲学不适合我，重构我的库以使用CommonJS的工作非常庞大。

所以，回到Grunt。一旦我了解了如何将项目导入Brunch，导入到Grunt是非常简单的。我在Windows上，所以所有的咕噜声使用grunt.cmd。

1. 呼叫grunt init:jquery（这可以在任何地方，我把创建的目录结构到我现有的项目文件夹）
2. 像早午餐，你会得到一个自动生成的目录结构和配置文件（grunt.js），但它的更薄，更薄。咕噜的配置看起来像这样：concat: { dist: { src: ['<config:lint.files>'], dest: 'dist/<%= pkg.name %>.js' } }, min: { dist: { src: ['<banner:meta.banner>', '<config:concat.dist.dest>'], dest: 'dist/<%= pkg.name %>.min.js' } }, qunit: { files: ['test/**/*.html'] }, lint: { files: ['grunt.js', 'src/**/*.js', 'test/**/*.js'] }, watch: { files: '<config:lint.files>', tasks: 'lint qunit' }
3. 这看起来有点不像我的想法，但它实际上非常优雅。 'min'属性定义了我的web应用程序将提供的最终的，连接的，分隔的和缩小的文件。它的源值是''，这是Grunt魔术来查看concat对象的dist dest属性值的值，然后从lint的文件的属性值派生出来。因此，您可以定义要分割，连接，缩小并输出到lint级别的目标的资源。
4. 一旦这件作品就位，您必须做一些额外的工作才能获得构建，监视和服务器部分。在咕噜，当服务器完成执行时，它退出。这意味着如果您执行grunt服务器任务，它将启动服务器，并且不执行其他任务，退出。
5. 我的第一个错误是通过设置watch.task ='server lint qunit'将服务器任务与手表任务捆绑在一起。这适用于您对源进行的第一项更改，但第二项更改将尝试在同一端口上启动第二个服务器实例并失败。相反，您可以注册一个任务grunt.registerTask('dev', 'server watch qunit');并调用grunt dev以使服务器以实时连续构建的方式运行。
6. 接下来，我的HTML内容取决于服务器端包含的组装页面。我无法弄清楚如何在Node中使用这个工具，并且客户端包括使用<object/>不起作用，因为它们将内容（在我的情况下是各种各样的<script/>和<link/>元素）插入到iframe中，这当然会打破我的模块模式（我的命名空间位于与iframe的窗口对象不同的窗口对象中）。幸运的是，grunt的concat对象是一个多任务，它可以连接任何东西。所以我将我的HTML文件添加到了concat中，并且我的单页应用程序已准备就绪。
7. 接下来，因为Node服务器运行在与我的IIS实例不同的端口上，所以您有跨域ajax问题。这SO article开始我的正确路径，但我最终需要对IIS默认内容标头进行以下更改：Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: X-Requested-With, X-Prototype-Version, Content-Type, Origin, Allow Access-Control-Allow-Methods: PUT, GET, POST, DELETE, OPTIONS Access-Control-Allow-Origin: http://localhost:88
8. 最后，因为我使用jQuery作为默认AJAX处理程序，所以我需要将此添加到我的ajax选项：xhrFields: { withCredentials: true }
9. 很明显，这里有安全隐患;但由于这只会影响我的开发环境，不会推到Production上，所以我认为它没问题。
10. 最后但并非最不重要，我花了一个小时试图通过Uglify，which was conveniently answered by this SO post来调试缩小错误。由于Visual Studio坚持以整个速度插入BOM（“UTF-8 With Signature”是委婉语），但UTF-8 Cast以快速顺序修复此问题。

一想到这一切，Grunt似乎工作得很好。我还没有机会在这个新的连续构建环境中开始测试实际的开发过程;但这是它能够开始的原因。

Answer 2

config.coffee是不是真的JSON，而不是真正的JS/CoffeeScript的，但为了编辑应该工作。你可以在具有确切配置顺序的早午餐​​bug追踪器中打开一个问题吗？

我不认为有重写您的应用程序使用的模块，而不是全局变量window的快速方式。顺便说一下，全局球员被认为是不好的口味。但你的解决方案可以工作，是的。