+1 The context is different for people building libraries and people building apps.
We are building an app and not having require.extensions would make our dev life more difficult because we would have to deal with the generated JS files somewhere in our source tree. We cannot just blindly exclude .js files from source control because we have a mix of .js, ._js, .coffee, etc. modules - sometimes in the same directory. But there is an even bigger problem for us: we need to distribute some of our source files in encrypted form. How could we do it without require.extensions? Bruno On Friday, May 10, 2013 4:02:19 PM UTC+2, 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.
