Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


Native CoffeeScript support #23

wants to merge 1 commit into from

3 participants


This is a required dependency to support pull request: substack/module-deps#17

It makes node-resolve in better alignment with the native node require/resolve functionality.

@kmalakoff kmalakoff referenced this pull request in substack/module-deps

Native CoffeeScript support #17


-1. That is not how node's module resolution works, so should not be the default.


@michaelficarra: if you require a javascript or coffeescript file without the file extension, they both resolve to javascript files. We only use coffeescript for Node.js and depend on that feature everyday.

Michael, I believe you are mistaken so you will need to explain yourself about why you believe this is not how module resolution works in Node.js.


Do you see .coffee there? require without an extension only supports .js, .json, and .node by default. The CoffeeScript compilers add .coffee to require.extensions to augment the default resolution. So you should need to use the custom extensions option to support resolving .coffee files.


@michaelficarra: you may be technically correct in terms of native resolution for coffeescript, but I didn't say native resolution (it is implied that coffeescript extensions are being used) - an extension approach would be great. The point of these two pull requests is to provide a way in browserify to act like node when you require coffeescript files.

I spent an afternoon wading through blog posts, github repos, and browserify-dependent modules about how to add this support because I was unable to find any examples where 1) you did not need to have pre-knowledge on which files have .coffee extensions (node does not require .coffee extensions in the require statements), 2) coffeescript files could require other coffeescript files because our libraries are more than one file deep. Both the coffeeify and transform solutions in the browserify README did not seem to handle these cases meaning they were not acceptable solutions and did not comply with how node handles required coffeescript files.

If you do not agree with this implementation, that is fine (I tried two different ways before coming up with these two pull requests), but you should not vote down the solution without pointing to a working solution in browserify using this extensions options you are suggesting. I'm fine for it to be reimplemented in a more configurable way, but it still needs to meet the use cases I've outlined.

I hope this clarifies the use case and explains what the node coffeescript community would need from browserify for proper and transparent support of required coffeescript files. Is it clear now?


As you suggest, this is more appropriate for browserify itself. When browserify uses this module, it should be passing ['.js', '.json', '.coffee'] as the extensions option (assuming it wants default CoffeeScript support). The resolve interface has the options parameter for this reason, as well as supplying a basedir and anything else that could modify the module resolution algorithm.


That sounds like a good solution.

@substack: I guess it is a question for you, would you like to support coffeescript by default or to have an option in browserify to enable this support? Either way is fine with me and I'm happy to redo the pull requests when I can find a moment.

@substack substack closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jun 24, 2013
  1. @kmalakoff

    Added coffeescript support

    kmalakoff authored
This page is out of date. Refresh to see the latest.
Showing with 1 addition and 1 deletion.
  1. +1 −1  lib/async.js
2  lib/async.js
@@ -20,7 +20,7 @@ module.exports = function resolve (x, opts, cb) {
var readFile = opts.readFile || fs.readFile;
- var extensions = opts.extensions || [ '.js' ];
+ var extensions = opts.extensions || [ '.js', '.coffee' ];
var y = opts.basedir
|| path.dirname(require.cache[__filename].parent.filename)
Something went wrong with that request. Please try again.