How to use regular CoffeeScript instead of CoffeeScriptRedux?

[myrne]

I've just been digging somewhat into commonjs-everywhere, and I think I like it a whole lot more than browserify. However, the fact that it uses CoffeeScript Redux is a problem for me (wish it were different...).

Documentation says about options.handlers:

"an object whose keys are file extensions ('.roy') and whose values are functions from the file contents to either a Spidermonkey-format JS AST like the one esprima produces or a string of JS. "

It seems I can use regular coffeescript by doing

jsAst = (require 'commonjs-everywhere').cjsify 'src/index.coffee', process.cwd(),
  handlers:
    '.coffee': (cSource, filename) ->
      (require 'coffee-script').compile cSource, 
        filename: filename
        bare: true

Do you know by any chance if it's possible to make this work with source maps too?
I'm not sure what kind of output commonjs-everywhere expects for this to work, and if I can get this data from the coffee-script module.

[michaelficarra]

You're going to need to generate an annotated SpiderMonkey AST somehow. You can of course parse the output of the compiler with esprima to get the AST, but I don't know of any tool that will take a source map and annotate an AST for you. @fitzgen: are you aware of such a tool?

[fitzgen]

I am not aware of any such tool.

[myrne]

Thanks for explaining. It had not been clear to me that the AST that Redux generates was annotated with source mapping data. Up to now, I've only worked with tools that spit out code and source map separately, so I was kind of expecting something like that.

[michaelficarra]

@meryn: Yeah, you should look at the esprima output when line- and column-based location tracking is turned on. Try out the online demo here: http://esprima.org/demo/parse.html. This is the structure that my compiler produces. escodegen creates a concrete syntax tree and asks mozilla/source-map to create a source map and JS program.

Since jashkenas/coffee-script only exposes the composition of those operations (because it never creates that IR in the first place), you need to find a way to do the inverse of what escodegen and mozilla/source-map do.

[myrne]

Thanks for the pointers!
I think I'm gonna be pragmatic for now and just accept absence of source maps all the way to the coffeescript source. I'll just compile the coffeescript with coffee -w, then have cjsify watch coffee's output dir.

[rymohr]

I'm interested in this as well. This is a great tool but I find myself wishing I could use the original compiler instead.

I frequently use standalone @ within my views and for writing chainable methods. Having to use this leaves a bad taste in my mouth. I've never had a problem with the way @ is handled in the original compiler, and judging by the lack of recent activity at coffee-script#1601 I doubt many others do either.

Hard to give up the source maps though!

[vendethiel]

Original compiler has source maps.

[rymohr]

@Nami-Doc according to the comments above it doesn't sound like they play well with this project though

[tarruda]

@fitzgen, @michaelficarra The implementation is really simple, check it out

@meryn, @islandr you can use the original coffeescript compiler or any transpiler that generates source maps with my fork

[michaelficarra]

@tarruda:

The implementation is really simple, check it out

That's awesome. Can you extract that to a separate project and publish it to npm? Even though it's small, it's not something we'd want everyone rewriting every time they need to do this.

[tarruda]

@michaelficarra good point, I will do it later when I get home

[myrne]

@tarruda Cool stuff. The SourcemapToAST function is remarkably simple, but it would probably have taken me ages to figure that out. I'll have a look at Powerbuild later.

@michaelficarra I suppose that with this function at hand, it would be relatively easy to write a CoffeeScript adapter for commonjs-everywhere. In fact, commonjs-everywhere could more or less consume anything that outputs source-mapped JS code.

[michaelficarra]

@meryn: Correct. When @tarruda publishes this module, I'll post a sample here.

[tarruda]

done : https://npmjs.org/package/sourcemap-to-ast

[rymohr]

@tarruda: Nice work! It looks like you're planning on maintaining your fork independently correct?

Back to those short and sweet @list.each(@renderOne, @) calls. Yay!

[tarruda]

@islandr Yes for now I intend to maintain my fork, at least until/if commonjs-everywhere(or any other npm browser bundler) achieves my performance requirements(I'd rather use a tool maintained by someone else though)

[michaelficarra]

@meryn:

cjse = require 'commonjs-everywhere'
coffee = require 'coffee-script'
escodegen = require 'escodegen'
esprima = require 'esprima'
sourceMapToAst = require 'sourcemap-to-ast'

jsAst = cjse.cjsify 'src/entry-file.coffee', __dirname,
  export: 'MyLibrary'
  handlers:
    '.coffee': (coffeeSource, filename) ->
      # use jashkenas/coffee-script, preserving source maps
      compiled = coffee.compile coffeeSource, sourceMap: true
      ast = esprima.parse compiled.js, loc: true, source: filename
      sourceMapToAst ast, compiled.v3SourceMap
      ast

{map, code} = escodegen.generate jsAst,
  sourceMapRoot: __dirname
  sourceMapWithCode: true
  sourceMap: true

@islandr: michaelficarra/CoffeeScriptRedux@b7b1a0d

[myrne]

@islandr Stand-alone @ is back in Redux master: michaelficarra/CoffeeScriptRedux@b7b1a0d

[myrne]

@michaelficarra I couldn't have imagined a better answer to my question. I get it handed on a golden plate. :)