That seems like a strongly worded, no. Maybe I'm unsafe, foolish, degenerate, and lacking in basic social skills (most likely true), but I still don't see the point.
By their very nature most of the compilers run in Node, so the idea of keeping them out of Node is kind of a moot point. Which means you have two paths: Current: Filesystem -> Node A (transpiles) -> Node A (program) Future: FIlesystem: -> Node A (transpiles) -> Filesystem -> Node B (program) If I distribute all of my code as javascript, I just don't see why in my own personal environment whether dev or on the server, that I wouldn't choose the first option there. Especially, if from my viewpoint, "coffeescript", "typescript" or whatever is the first class language, not javascript. And you can say it's bad and there are bugs, which is cool, but if you guys won't support it, I can pretty much guarantee you that userland will bring it back anyway. On Sunday, May 12, 2013 4:02:21 PM UTC-5, Isaac Schlueter wrote: > > > It would be nice if the wonderful core guys would tell us that it's cool > to use transpiled languages in our applications, as long as we keep it out > of npm. > > We are telling you it's fine to use transpiled languages as long as > you keep them out of Node. Transpile them to JavaScript. Run > JavaScript in Node. > > Relying on require.extensions is explicitly not encouraged, nor > supported. It has known bugs *today*, which will not be fixed, ever. > It is very brittle and cannot be made any less brittle. It is a > global switch by which one module can introduce subtle bugs in another > module. It is tight coupling and unnecessary run-time complexity. > It's everything we try to *avoid* in Node. > > Take it up with the CoffeeScript maintainers to stop relying on and > encouraging this dangerous, unsafe, unwise, deprecated practice. Even > long-time coffeescript users are teling you here to avoid using the > require hooks. The "build step" takes milliseconds, and can be set up > to run in the background automatically. There is absolutely zero > reason to insist on using techniques that are known to be problematic, > and even less to insist that we support them. > > Of course, it's your computer, it's your application, you can do > whatever foolish thing you want. But if you're looking for my > blessing, then don't do foolish things. It would be irresponsible of > me to say this is OK when I know it isn't, since I see the fallout > from the bugs it causes. > > > > > On Sun, May 12, 2013 at 1:38 PM, Brad Carleton > <[email protected]<javascript:>> > wrote: > > As an author of a couple of coffeescript projects in node, I agree the > code > > that goes into npm should NOT be coffeescript. That being said when you > are > > developing an application, adding an explicit build step is not fun. I > mean > > I wouldn't want to see all the assembly or binary files that my > javascript > > code could be compiled into. > > > > I think other dialects of javascript are a great thing. There are a lot > of > > developers from varying communities ruby, python, .NET, java, who may > never > > come over to the node/javascript world unless these transpiled languages > > exist. I came from python, and being able to walk into coffeescript > felt > > vary comfortable for me. Now, I contribute to the node community, but I > > don't write javscript. Yes, in an ideal purist world everyone writes > > javscript, but then there are less people in the community because > people > > tend to be biased towards languages. Beyond that, some people are just > more > > or less productive in some languages versus others. > > > > It would be nice if the wonderful core guys would tell us that it's cool > to > > use transpiled languages in our applications, as long as we keep it out > of > > npm. Furthermore, if they truly don't want to support > "require.extensions", > > they should at least be supportive of userland setting up a hack to > bring it > > back. I mean that would be dead simple. Replace the global require > with a > > custom object that adds the require.extensions functionality back, and > then > > package it up in an npm module, called "good-ole-require"! > > > > > > > > > > > > On Saturday, May 11, 2013 9:38:12 PM UTC-5, Isaac Schlueter wrote: > >> > >> My thoughts on the matter are articulated in the issue linked in the > >> OP. Also everything that Ben has written in this thread is 100% > >> correct. > >> > >> Furthermore: > >> > >> We only remove/break deprecated APIs if they're in the way. If it's > >> buried in a locked module, then that's highly unlikely. (Someone > >> would have to find an extremely severe bug that could only be fixed by > >> removing require.extensions.) > >> > >> However, we also aren't likely to *fix* any issues that you have with > >> that deprecated API. That's the issue that started this round of > >> require.extensions discussion. The only change that we'd make to it > >> is to remove it or add a deprecation warning, and we won't be doing > >> that, since there's no reason to. > >> > >> In the near future, the module rating system that we're building will > >> penalize any module that uses deprecated APIs. It will be ranked > >> lower in searches, have a smaller score next to its name, and perhaps > >> even print a warning when it is installed by npm. > >> > >> If you would like to ensure that your program is not doing anything > >> stupid, you can use the `node-strict` module, and add > >> `require('node-strict')` to your main file. It's still a work in > >> progress, but it prevents require.extensions and other poor choices. > >> > >> > >> On Sat, May 11, 2013 at 7:00 PM, Bruno Jouhier <[email protected]> > wrote: > >> > Cool cause I need this to work forever: > >> > https://github.com/bjouhier/node-lol > >> > > >> > OTHERWIZ DAZ NO FUN! > >> > > >> > Sorry for my lolcat, it's a bit weak. > >> > > >> > Bruno > >> > > >> > On Sunday, May 12, 2013 1:56:23 AM UTC+2, Ben Noordhuis wrote: > >> >> > >> >> On Sat, May 11, 2013 at 9:05 AM, ~flow <[email protected]> wrote: > >> >> > what conventions / best practices / techniques can we come up that > >> >> > will > >> >> > allow us to 'publish in my language, run as javascript' the day > that > >> >> > require.extensions is gone? > >> >> > >> >> What seems to be getting lost in this discussion is that > >> >> require.extensions is not actually going away, certainly not in the > >> >> near future and probably never. > >> >> > >> >> Deprecation in API-locked parts of node.js core means "you really > >> >> shouldn't use this", not "we'll remove it whenever the fancy strikes > >> >> us." > >> > > >> > -- > >> > -- > >> > 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. > >> > > >> > > -- -- 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.
