将现有JavaScript项目导入到Grunt / Brunch项目

我看了保罗·爱尔兰人的讲话,宣布了Yeoman(www.yeoman.io),而且我迷上了运行连续构build环境的概念。 不满意等待一个文曼的邀请,我尝试了咕噜和早午餐。 两者都可以轻松安装,而且我可以用最less的努力启动并运行新的项目。

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

我有至less200个模块和许多简单的辅助函数导出到命名空间; 因此使用控制台在grunt / brunch项目中创build这些控制台并且单独手动导入每个模块并不是很有效。 此外,我正在使用至less15个不同的第三方JavaScript工具。 我不清楚如何把这些东西带进去。

什么是最有效的方式来采取一个大的,现有的项目,并将其迁移到Grunt /早午餐最小的重构和支持任意的第三方工具?

更新 :这两个,我发现早午餐更容易应付。 如果你使用股票“骨架”(即“模板” – 从命令行{在你想要更改的文件夹中执行]执行“brunch new [project_name] –skeleton git://github.com/brunch /simple-js-skeleton.git“)为纯JS,你会得到一个新的文件夹结构,实际上是相当敏感的。 当你运行“早午餐”时,任何你进入“应用程序”(你自己的代码)或“供应商”(第三方)文件夹的文件都会自动重新编译。

这很好,除了。 根据文档,您可以控制订单供应商脚本从Brunch config.coffee文件(JSON文本文件)编译和连接在一起。 对这个文件的改变似乎没有任何效果,所以你最终会得到期待其他插件的插件的第三方竞争条件。

而且,当你把你自己的代码放到自动创build的“app”文件夹中时,你会得到一个自动编译的,即时编辑的代码版本; 但是无法访问 早午餐模糊窗口对象,所以我的初始命名空间声明window.myNameSpace失败,所有后续库调用命名空间也失败。 这与Brunch的模块系统有关,对此我找不到任何文档。

我通过将我的命名空间类放在'vendor'文件夹中来解决这个问题,这个文件夹确保它连接到窗口对象; 然而,现在有一个竞争条件:我的名字空间并不总是可用于我所有的模块。

现在的问题是这样的:

将所有内部和外部库复制到Brunch项目后,如何将应用程序configuration为按照正常顺序加载它们?

这是一个点子,但我终于明白了。 当我开始使用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. Brunch使用以下内容在目录结构的根目录下创build一个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'属性让我感到困惑,直到我意识到'javascripts'实际上只是'客户端代码'的一个掩码,而'apps.js'实际上是一个调用'get all * .js文件文件夹“app”,recursion地“。
  5. 一旦明确,您只需将您的内容放入“应用程序”即可。 我将我的* .html和图像文件放入“assets”子文件夹中,并将所有JavaScript内容放入lib中。
  6. 此时,您可以运行brunch build和brunch watch,并且您的项目已启动并正在运行,在您进行更改时实时编译,在浏览器中实时重新加载。

虽然Brunch在使用第6步的时候比Grunt更擅长,但是对于我来说失败的是早午餐中编辑的本质。 每个JavaScript文件都被包装在CommonJS模块中,模块名称基于相对path和文件名('lib / core / ajax'等)。 CommonJS哲学不适合我,重构我的图书馆使用CommonJS的工作是巨大的。

所以,回到Grunt。 一旦我了解了如何将项目导入Brunch,导入到Grunt是一个很好的方法。 我在windows上,所以所有的咕噜声使用grunt.cmd。

  1. 调用grunt init:jquery (这可以在任何地方,我把创build的目录结构移到我现有的项目文件夹中)
  2. 像早午餐一样,你会得到一个自动生成的目录结构和configuration文件(grunt.js),但是它要薄得多。 Grunt的configuration如下: 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. 一旦这个部分到位,你必须做一些额外的工作,以build立,观看和服务器件。 在咕噜,当服务器完成执行,它退出。 这意味着如果你执行grunt服务器任务,它将启动服务器,并且没有其他任务要做,退出。
  5. 我的第一个错误是通过设置watch.task ='server lint qunit'将服务器任务捆绑到手表的任务上。 这适用于对源进行的第一项更改,但第二项更改将尝试在同一端口上启动第二个服务器实例并失败。 相反,你可以注册一个任务grunt.registerTask('dev', 'server watch qunit'); 并调用grunt dev来使服务器运行实时,持续的构build。
  6. 接下来,我的HTML内容依赖于服务器端包含来组装页面。 我无法弄清楚如何在Node中得到这个工作,而客户端包括使用<object/>不起作用,因为它们插入内容(在我的情况下是各种<script/><link/>元素)到一个Iframe中,这当然会打破我的模块模式(我的命名空间是在一个不同的窗口对象比内联框架的窗口对象)。 幸运的是,grunt的concat对象是一个多任务,它可以连接任何东西。 所以我添加了我的HTML文件concat,并且我的单页应用程序准备好了。
  7. 接下来,因为Node服务器运行在与我的IIS实例不同的端口上,所以你有跨域的Ajax问题。 这篇SO文章开始了我的正确道路,但是我最终需要对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. 显然,这里有安全隐患。 但是因为这只会影响我的开发环境,不会被推到生产环境,所以我认为没关系。
  10. 最后但并非最不重要的,我花了一个小时试图通过Uglifydebugging错误的缩小, 这是SO这个职位很方便的回答 。 由于Visual Studio坚持以整个速度插入BOM(“UTF-8 With Signature”是委婉语),但UTF-8 Cast快速地修复了这个问题。

一旦我明白了这一切,Grunt似乎工作得很好。 我还没有机会在这个新的连续build造环境中开始testing实际的开发过程。 但是这是能够开始的。

config.coffee不是真正的json而不是真正的js / coffeescript,但是编辑顺序应该是可行的。 你能否在早午餐bugtracker中以确切configuration顺序打开一个问题?

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