Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Support iced-coffee-script as alternative compiler #319

wants to merge 1 commit into from

4 participants


If it can't find the coffee-script package, it looks for iced-coffee-script as an alternative.


I absolutely love mocha's support for coffee-script!

  1. I'd go the other way around -- first try to require iced-coffee-script, and if that's not found, then try coffee-script. I've actually got both coffee-script and iced-coffee-script in my node_modules at the moment (while I evaluate iced and make up my mind whether I want to run with it, and figure out what to do with things like eco that don't know about iced). If both are present, it seems like Mocha should prefer the one with more features.
  2. If iced is loaded successfully, shouldn't you also set re = /\.(js|coffee|iced)$/;, so it will recognize tests with the .iced extension?
tj commented

it's lame enough that we support coffeescript, I dont want to go accepting any more into projects until they have reasonable adoption. sorry :( we just cant keep doing this in every project it's really lame, tamejs, haskelljs, iced-coffee, coffee-script blah blah.


@joewhite Yeah, I debated that when I was putting this together. Since iced (in theory) is fully backward compatible, you're probably right. And re 2, yeah, right again.

@visionmedia I understand. In that case, what about a way to hook into mocha and provide custom compilers? Maybe something like --add-compiler extension:require_path. That way I could do --add-compiler iced:iced-coffee-script and someone else could do --add-compiler myext:./my_local_compiler. Would you accept a PR that does that?

tj commented

@iangreenleaf yeah I would much rather do that, good plan. Let's remove coffee-script OOTB. I haven't confirmed but even --require coffee-script etc should be fine, other than the extension lookup deal

tj commented

I guess let's do --compile coffee:coffee-script to introduce the extension for that regexp


@visionmedia true about adding explicit support for every node.js interpreter - i think that is a node.js bug, should be a way to run everything with node but have some kind of directive that tells it which interpreter to use.

Mocha is another example of the same problem. Should be able to do something like node myfile.js, where myfile.js has something like (for example)
#!/usr/bin/env node
#interpreter = /usr/bin/env mocha
#mochaopts = -u tdd -R tap -t 80000 -b

if there were such a mechanism then all things could be run from node directly, and thus mocha would not care whether something is in coffee, javascript, or anything else.

tj commented

well it's not really node's issue either, node didn't ask for people to write languages that compile to js. they're lucky they can even hook into require() to make it less painful in the first place


Yeah, the require support for compilers is actually pretty nice (excepting my one beef). Maybe just need a better way to load those hooks in the first place. If my package.json could specify which compilers to load or something, then I wouldn't need to depend on various libraries (mocha, supervisor, etc) to be able to do it.

tj commented

yeah, if you can convince isaac, wont be easy :p but yeah something higher-level could take that annoyance off of other maintainers


Alternate solution was merged, so this is resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Mar 14, 2012
  1. @iangreenleaf
This page is out of date. Refresh to see the latest.
Showing with 5 additions and 1 deletion.
  1. +5 −1 bin/_mocha
6 bin/_mocha
@@ -165,7 +165,11 @@ var files = program.args
// coffee-script support
try {
- require('coffee-script');
+ try {
+ require('coffee-script');
+ } catch (err) {
+ require('iced-coffee-script');
+ }
re = /\.(js|coffee)$/;
} catch (err) {
// ignore
Something went wrong with that request. Please try again.