1. 11

Many tools written in node.js just use a JSON file (or a JSON-like file, like yaml or hjson) for configuration. That works well for some stuff (except JSON; that’s generally a pain to write and has no comments), but they’re all sorely missing a way to spread your configuration out across multiple files.

HConfig my project to remedy that problem for my own projects; a dependency free parser for a new, JSON-like configuration format which makes it possible to include other files. I figured I’d put it on github and share it with the world. I’m also interested in constructive feedback.


  2. 6

    I like the syntax, but I’m wondering if this isn’t just a xkcd #927 situation. What does this solve that toml doesn’t? Having native support for file inclusion is a great idea, but why not use a well-defined key in YAML/HJson/Toml and wrap one of them in a library that handles it for you?

    100% agree with JSON-as-configuration; I wish that idea would go away.

    1. 2

      It would be hard to add something like this to a YAML/HJson style format because of its syntax - you can’t really just look for say a key named “include”. You’d have to walk the entire object if you want to be able to find it everywhere, and even if you did that, you would probably want to define some parts of an array in one file and one in another. Since arrays don’t have keys, that’d be kind of hard. You could look for some string (say #include "filename"), make sure it’s not within a string literal, and do a string replace with the content of that other file, but that sounds like a big hack and would give terrible error messages.

      TOML, on the other hand, is more interesting. While I have looked a bunch at it in the past, I hadn’t considered it for this. Since its syntax is flat (even though it can represent hierarchical structures), it should be completely doable. Personally though, I have never been that big a fan of INI-style syntax. I also don’t really think it’s that important to standardize on one particular thing; I think it’s nice to have an open marketplace of ideas (at least when there’s no officially sanctioned solution for the platform you’re using). I think, for the project I created HConfig for, HConfig’s syntax will be nicer than TOML’s, even though you could implement the same functionality with TOML.

      Another factor is that I just like inventing syntax for languages and creating parser :P

    2. 2

      This looks cool, but also quite similar to HCL: https://github.com/hashicorp/hcl

      They’re both basically curly-braced nginx-style config languages that evaluate to JSON.

      1. 2
      2. 1

        Have you considered support for remote+dynamic config? I’ve a co-developed such a thing for Java (https://github.com/irenical/jindy) but we never found a Node equivalent. In the Java ecosystem a lot of the pieces were already there, so this is basically an API and glue. If one would want to centralise configuration using Consul, etcd or what have you, what would you suggest? What about if you need to react to runtime config changes? Do you see these features as something that would make sense in HConfig? I’m really trying to avoid having to write a “jindy.js” from scratch.

        1. 1

          Hmm, I don’t know if that would make sense in HConfig. It’s more supposed to just be a parser for a language. However, it would totally be possible to build something on top of that which uses HConfig as a configuration language. Reacting to runtime config changes would probably also be up to the application or another language to implement; just parse the file again whenever you want to reload it, and do whatever application logic is necessary to incorporate the updated configuration.

          1. 1

            We use HOCON, which, used with the typesafe config jars, has wonderful support for overriding values. The idea is that each jar can have it’s own reference.conf, and then you can add a new config file with a fallback to the default. So you can read config from consul or etcd and then use it to override the default values, We use typesafe config a lot and it makes our lives a lot easier. We use a single object which contains all of the config values which we care about. This is immutable and typed. If we need to re-read (because of changes in consul), then we re-read and we have a new immutable object.

          2. 1

            Also seems very similar to hocon

            1. 1

              Doesn’t it make sense to use JavaScript Object Notation to configure a JavaScript project?

              If you really need more power then JSON is giving you, what’s stopping you from writing tools in the language you already have? (JavaScript!)

              1. 1

                JSON really isn’t a nice configuration language. You have to quote all keys, which is annoying. Comments are forbidden. Trailing commas are forbidden, making reordering stuff a pain. It has no way of spreading configuration across multiple files. It’s a great human readable data interchange format, but not a great configuration format.

                You’re right that it would make sense to write tools for JavaScript in JavaScript, which is why HConfig is written in JavaScript.

                1. 1

                  I was suggesting writing tools to support a config.js file instead of a config.json file.