> If I had a time machine, and could go back to 2010 and do it again, I
> would do all that I could to prevent require.extensions from even
> being added.  At the time, I thought it was a good idea.  In
> retrospect, I was wrong.  It has only caused problems.

> Here's a better approach than require('coffee-script') to set up the
> require hook: publish and run JavaScript.

> There are a few ways to do this.  The first way is to write
> JavaScript, in files with a '.js' extension.  A lot of us do that, and
> find that it's pretty nice.  But clearly, the coffee-script and
> streamline communities have already decided against this for various
> reasons.  That's fine.

> The second way is to write some other language, but compile it to
> JavaScript.  For development, both streamline and coffee-script have
> fs.watch hooks that can do this on every file change.  For deployment,
> you can set up a "prepublish" script in your package.json to do this,
> and make sure that the .js files aren't excluded from the package
> tarball.

> The third way, which is sadly very common, and also in my opinion
> presumptuous and divisive, is to expect your users to load
> coffee-script or streamline themselves, and then use an alternative
> module loader to load your library.  This segments the community
> unnecessarily.

> It is presumptuous because it places unnecessary requirements on your
> users simply because you would prefer not to add a few lines to your
> package.json file, or because you don't realize that there is a way to
> use your alternative compile-to-js language responsibly.

> It is divisive because many users will simply not use your module
> because it adds an extra compilation step at run-time, and is written
> in a language that they are unfamiliar with.  (We can debate the grade
> of the learning curve, but it's clearly not zero.)  As a result, many
> users will simply not use your application, and coffee-script or
> streamline become their own islands.  This introduces unnecessary
> social barriers to using your module, and is bad for the entire
> JavaScript community.

> Please stop requiring coffee-script at run-time.  Write whatever you
> want, but please just serve JavaScript.

> On Mon, Apr 23, 2012 at 06:44, Aseem Kishore <aseem.kish...@gmail.com> wrote:
>> Good point, thanks.

>> Short of changes w/in Node, your getRequire() method would work. It loses
>> some elegance though. =) How about this instead?

>> require = require('coffee-script').register(require)

>> Ultimately, I think all of these issues would be simplified significantly if
>> require hooks were functional and side-effect-free. E.g. *returning*
>> compiled content instead of passing it directly to module._compile. I'd
>> brought this up a long time ago on the lists; let me think about it more and
>> offer a concrete proposal.

>> CoffeeScript team, sorry -- I've been using CS as an example just because
>> it's more commonplace -- I don't mean to be presumptuous. What are your
>> thoughts? Is concern over potential versioning conflicts in the future a
>> reasonable concern?

>> Aseem

>> On Mon, Apr 23, 2012 at 5:21 AM, Bruno Jouhier <bjouh...@gmail.com> wrote:

>>> require = require('coffee-script').require

>>> won't work because it won't be able to handle relative paths. You'd need
>>> something like:

>>> require = require('coffee-script').getRequire(__dirname);

>>> The require function would need to install the hooks, run the native
>>> require and then uninstall the hooks. A bit complex but why not.

>>> Another approach is to say that language tools should be backwards
>>> compatible. Then what matters is that hooks of higher version always
>>> override hooks of lower version. Easier to implement.

>>> On Sunday, April 22, 2012 2:52:40 AM UTC+2, Aseem Kishore wrote:

>>>>>  require = require('coffee-script');

>>>> Argh, sorry -- that should be something like this:

>>>> require = require('coffee-script').require;

>>>> Aseem

>>>> On Sat, Apr 21, 2012 at 8:51 PM, Aseem Kishore <aseem.kish...@gmail.com>
>>>> wrote:

>>>>> (Changing to own thread)

>>>>>>  The "local custom require" would be a bit tricky because every module
>>>>>> receives its own require function.

>>>>> Yep, that's why I suggested that the compiler could automatically inject
>>>>> the same one-liner to get a local require() into any file it compiles.

>>>>> Currently, to compile CoffeeScript or Streamline, you put this at the
>>>>> top of your main/loader file:

>>>>> require('coffee-script');

>>>>> That changes global state. As our tools continue evolving, that sucks
>>>>> because a module further down might require() a different version of
>>>>> CoffeeScript, and the global state would get overwritten and might conflict.

>>>>> So my suggestion is that, instead, you would put *this* one-liner:

>>>>> require = require('coffee-script');

>>>>> The implementation internally would mostly be the same -- the hook would
>>>>> check the file extension, and if it was .coffee, it would read the file and
>>>>> compile it before handing it to Node.

>>>>> But it would do one extra thing: inject this same one-liner to the top
>>>>> of the generated JS. That way, everything continues to "just work", but no
>>>>> more shared global state / possible version conflicts.

>>>>> What do you guys think?

>>>>> Aseem

>>>>> On Fri, Apr 20, 2012 at 3:24 AM, Bruno Jouhier <bjouh...@gmail.com>
>>>>> wrote:

>>>>>> The "local custom require" would be a bit tricky because every module
>>>>>> receives its own require function. This is needed to resolve relative paths.

>>>>>> [...]

>>>>>> Bruno

>>>>>> On Friday, April 20, 2012 5:43:27 AM UTC+2, Aseem Kishore wrote:

>>>>>>> If I have a module in e.g. CoffeeScript, I would think that clients
>>>>>>> that require() the module shouldn't need to compile the CoffeeScript on the
>>>>>>> fly via CoffeeScript's just-in-time require() hook -- both for performance
>>>>>>> but also because require() hooks are global*, which could lead to version
>>>>>>> conflicts.

>>>>>>> [...]

>>>>>>> * I've been thinking about the global require() hooks because I've
>>>>>>> been bitten by it before. I offer a suggestion to Node and/or
>>>>>>> CoffeeScript/etc. to support "local" custom require()'s instead of global
>>>>>>> ones?

>>>>>>> require = require('coffee-script').require
>>>>>>> require 'foo'    # if foo is a coffee file, will "just work" -- and
>>>>>>> the line above will be injected into the top of the compiled JS too in case
>>>>>>> it require()'s other coffee files

>>>>>>> Same could apply to Streamline, etc.