I agree with that. npm modules should be compiled to js. I even suggest them to be concatenated and minified for performance reasons, why don't anybody do that?
But it's NOT about published npm modules. It's about developing. When I develop my coffeescript libraries (see https://github.com/rlidwka/asset-pipeline for example), I put 'module.exports = require("./src/index");' in index.js and using on-the-fly compilation. On production system I change it to require("./lib/index") to use compiled version. So, how am I supposed to do this without require.extensions? Oh... well, you're right, it'll probably be require("good-old-require")("./src/blablabla.coffee") with a help of a library that would reimplement all filesystem searching/reading stuff by itself all over again. How will require("something.json") be dealt with anyway? On Friday, May 10, 2013 2:02:19 PM UTC, Eldar wrote: > > No one argues about modules for npm. What about apps? What about > components private for organization? > > There is never any need for additional filetype extensions. Node runs >> JavaScript. Ultimately, you have to compile it to JS before it runs * >> anyway*, so you may as well do that up front, rather than adding a >> global hook for it. > > > Ok, Then we'd like to see setups as simple as `mocha --requrie FooLang` > for running tests and `node ./support/foo script.foo` for everything else. > > On Friday, May 10, 2013 5:16:18 PM UTC+4, Ben Noordhuis wrote: >> >> On Thu, May 9, 2013 at 5:29 PM, ~flow <[email protected]> wrote: >> > i recently opened an issue https://github.com/joyent/node/issues/5430 >> > concerning require.extensions, and got told that >> > >> > "People should not be using require.extensions. It's officially >> deprecated", >> > "Compile your code to JavaScript prior to running it." "There is never >> any >> > need for additional filetype extensions. Node runs JavaScript"; "we're >> not >> > bothered with tens of other dialects that require compilation and are >> > written in code that's not readable for JavaScript programmer"; "stop >> > relying on this horrible feature" >> > >> > in no unclear words. i was a little shocked, since my perception has >> always >> > been that require.extensions was the strike of a genius. with little >> effort, >> > you can hook in filetypes and make it so that they are require'd >> > transparently, no matter whether they represent data / programs as >> > javascript, json, coffeescript, whatever. >> > >> > ok it's a global hook which, in theory might lead to problems (but in >> years >> > of writing coffeescript hasn't been a problem even once. >> > >> > i love the fact that i do not have to compile everything in advance / >> add a >> > buildscript / are forced to keep a coffeescript watch process in the >> > background. coming from python, i was also very happy to see that those >> > pernacious *.pyc files that used to litter my directories were now a >> thing >> > of the past—i mean, that is code duplication enforced by the system, >> utterly >> > avoidable. >> > >> > to me, javascript is a wonderful language with some rough edges and a >> > horribly cluttered syntax. now here comes nodejs and all those >> wonderful >> > home-grown programming languages that take advantage of the great >> compiling >> > target that javascript running on nodejs is. dumbing down `require` >> will be >> > sad news for all the many people that are using those new languages >> daily. >> > >> > as a user of coffeescript, the fact that coffeescript compiles to >> javascript >> > is a fact that i have to be aware of, but it is not something that i >> want to >> > be (or need be) constantly reminded of. doing on-the-fly, transparent >> > compilation is the way to go; it has never been any appreciable drain >> on >> > resources, either. it sure will continue doing things that way. >> > >> > if they kill require.extensions with no sensible replacement, things >> will >> > just get more difficult. it won't be too difficult to come up with a >> > sensible replacement—one could even predict that sooner or later, there >> will >> > be modules in npm that will allow you to `require 'old-require'` to >> replace >> > the new require with the good ole'. gone a bit of efficiency, gone a >> bit of >> > standardization. >> > >> > so what are the good, the bad and the ugly facts about >> require.extensions? >> >> You're essentially saying that deprecating require.extensions makes >> your life as a module author harder, right? That's the wrong way to >> look at it: it makes life for _users_ of your module easier. >> >> The quintessential example is where someone has a project that depends >> on two modules, both written in FooScript(TM), but with module A >> depending on [email protected] and module B depending on >> [email protected]. >> >> require.extensions is global; if FooScript 1 and 2 are incompatible, >> then your user is between a rock and a hard place - there is no way >> for him to use both modules at the same time. >> >> That's why we _strongly_ recommend that you compile to JS before >> publishing to npm. You are doing your users a disservice if you >> don't. >> > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
