+1

+500!

+1

I agree. JSON is the de facto standard for configuration or data files in Node.js. I always have to write the same wrapper.

+1

This would be handy, sure. Even though I know it's probably overkill for node I figured I'd throw out the AMD plugins option. It'd also be useful for other kinds of require branching like i18n and other potentially useful resource parsers ("yaml!config.yaml"). Oh, and I think there was some interest in requiring from a zip archive -- all those kind of things could be done easily from userland.

But yeah, another level of misdirection sucks, so my guess is this is a non-starter -- just figured I'd chuck it out there again. I remember there being some interest in getting require.extensions to compose better -- this is one possible approach, but I have no idea how well this would interact with the current require.extensions stuff (my guess is poorly). But one way or another, I'd kill for a straitforward, composable way to hook into require.

+100

+9001

There needs to be a "Like" or "+1" button for GitHub comments (or whole threads). <3

+1!!!!

FYI, we use nconf for this. Once you get the idea of using json based configuration files, having a friendly interface to your JSON tends to help.

https://github.com/indexzero/nconf

@isaacs Do you think it would be useful to try to make this operation "safer"?

require.extensions[".json"] = function (m) {
  try {
    m.exports = JSON.parse(fs.readFileSync(m.filename));
  }
  catch (ex) {
    m.exports = {};
  }
};

It seems like it would save a lot of users from having to constantly wrap their require() statements to safe-guard against potential parse errors.

+1 overall though

+1 from me, it's small enough to be a "why not"

+1

@indexzero Good idea, although I'd be more inclined to make it null or false, that way one can differentiate between parse errors and empty files.

Gosh, that's a great idea. I feel really dumb now for doing something similar but not nearly as neat using the vm module.

I had a libYAML binding lying around that I was working on a while ago. Couldn't resist putting this in and publishing to npm (as package libyaml).

The bindings parse a good deal of YAML, and should be able to deal with most anything using it for configuration. Some fancy features (anchors and whatnot) are unimplemented, and serializing is very incomplete.

for .json I think you'd want to know of the parse errors, could be potentially confusing otherwise

@indexzero Getting a parse error seems consistent with requiring invalid JS. You don't get an empty object back if there is a JS parse error.

Related #584

@indexzero I think @josh is right. require() is sync, and can throw
if the file isn't found or is invalid, so throwing JSON errors seems
more appropriate than handling them internally.

On Mon, Jul 18, 2011 at 12:49, josh
reply@reply.github.com
wrote:

@indexzero Getting a parse error seems consistent with requiring invalid JS. You don't get an empty object back if there is a JS parse error.

Related #584

Reply to this email directly or view it on GitHub:
#1357 (comment)

@deanlandolt Yeah, that stuff is a much bigger discussion. I'm of the opinion that stuff like archive require()ing and adding syntax should not be in node-core. JSON parsing is built into the language already, so it's pretty easy.

+1

+42

nice. +1 for not catching errors.

+1

I like this idea but I've never felt much pain in loading my configs like this:

var config = require('config')

where config.js is:
module.exports = config = { ... }

Check out this commit:
thurmda/hummingbird@fdb97bb

Technically my config is a module that exports and object literal, which I find a bit nicer than writing strict json ( " vs ' etc.)

A good improvement might be to add a default object when then file is not found.

A good improvement might be to add a default object when then file is not found.

-1, this would bring inconsistencies to the way require works, when a file is not found, it should throw in all cases.

Maybe. I try to avoid exceptions. I would prefer to have null returned or a default config object if set as a second parameter, because that's what I would do next. I'll probably have to wrap require() around my own method.

If you scroll up the thread you'll notice that @josh explained why this is not the best implementation.

Even all this time later I'd like to just say 👍