在实现 RequireJS 的同时继续使用 CoffeeScript 进行开发答案

【问题标题】：Continuing development in CoffeeScript while implementing RequireJS在实现 RequireJS 的同时继续使用 CoffeeScript 进行开发
【发布时间】：2014-03-29 20:13:08
【问题描述】：

我想在一个使用 CoffeeScript 和 Grunt 的大型单页应用程序中实现 RequireJS。我们为不同的模块（服务、Backbone 等）提供了单独的文件。

实现 RequireJS 非常简单——我的主要问题是应用程序的大小和 CoffeeScript 的空白敏感性。我们需要能够在实现 RJS 的同时不断开发新功能。我们不能这样做的原因是我们必须将所有文件包装在定义调用中，并重新标记文件。当你尝试 rebase 这段代码时，大量的合并冲突会因为 tabbing 而出现。没有人有时间解决所有这些问题，因为在 RJS 之前可能已经引入了新功能和错误修复。

我研究了一些可能的解决方案：

停止开发并重新标记所有内容。这很糟糕，因为在文件被标记并且代码实际上可以与 RJS 一起使用之前，开发会停止。
使用CommonJS模式，并使用RJS CommonJS转换器pre-RJS优化。看起来很老套。
使用 CoffeeScript backtick 功能将 CoffeeScript 类包装在标准 JavaScript 模块模式中。接下来将依赖项传递给 CoffeeScript 类的“模块”包装器，然后在文件中的 RJS 调用中初始化“模块”。

编辑：感谢您提供有关垂直结构的提示并向我介绍以这种方式传递函数参数（无逗号）。我们的项目在结构上非常相似（不幸的是，目前除了 grunt-contrib-coffee 进行 linting），而且我还在构建一个自定义 watch 任务来编译单个文件（与 glob 模式相比）。

考虑这个非常基本的例子：

view.coffee:

class View
  template: Helper.template
  constructor: (@options) ->
  render: (meters) ->
    $('body').html @template @options

正常的过程是使用 RJS 执行以下操作：

define [
  'jQuery'
  'Helper'
], (
  $
  Helper
) ->
  class View
    template: Helper.template 'base_view'
    constructor: (@options) ->
    render: (meters) ->
      $('body').html @template @options

注意整个班级是如何被重新标记的。如果我们的任何开发人员出现并修改 View 类，而我正在尝试并行实现 require，Git 会讨厌这种情况。

反引号的想法行不通，我无法解决那里的全球问题：

`var exports = function($, Helper) {
class View
  template: Helper.template
  constructor: (@options) ->
  render: (meters) ->
    $('body').html @template @options
return View }(jQuery, Helper)`

define [
  'jQuery'
  'Helper'
], (
  $
  Helper
) ->
  return exports($, Helper)

我认为我最好的选择是将所有应用程序功能合并在一起，然后暂停片刻以重新标记每个文件所需的两个空格，所有这些都在一次提交中完成。只要文件的其余部分遵循该模式，CoffeeScript 似乎并不关心缩进从哪里开始（第 0 列与第 2 列）。我们应该能够在 RJS 中滑动并以这种方式逐步实现它，防止无法解决的合并冲突。

【问题讨论】：

标签： coffeescript gruntjs grunt-contrib-requirejs

【解决方案1】：

我们在项目中所做的：

我们使用grunt-contrib-coffee 和grunt-coffeelint 来编译和验证咖啡文件。使用此插件，您可以在开发时验证咖啡脚本代码。您可以使用包含验证设置的 json 文件。这样可以确保所有开发者都使用相同的设置。

例如：

{
  "no_tabs" : {
    "level" : "error"
  },

  "no_trailing_whitespace" : {
    "level" : "error"
  },

  "max_line_length" : {
    "value": 200,
    "level" : "error"
  },
  ...

通过在单独的行上定义每个依赖项，最大限度地减少 requirejs 依赖项中合并冲突的机会。

例如

define [
 'dep1'
 'dep2'
 'dep3'
], (
  dep1
  dep2
  dep3
) -> 
  console.log "Hello"

而不是

define ['dep1', 'dep2','dep3'], (dep1, dep2, dep3) -> 
  console.log "Hello"

仅将咖啡脚本文件提交到源代码管理。生成的 javascript 文件（通过 grunt-contrib-requirejs 缩小）我们不提交（仅在创建生产版本时）。
我们使用自定义监视任务来监视更改的咖啡脚本文件（以及其他文件）。当编译或验证失败时，通过growl 通知开发者。

【讨论】：