I have a little class for loading a config file:

// index.js:

class Config {
    constructor(path) {
        this.path = path || this.defaultPath;
        this.config = fs.readFileSync(this.path, { encoding: 'utf8' });
        this.config = JSON.parse(this.config);
    get() {
        return this.config;
Config.prototype.defaultPath = './config/config.json';

module.exports = {
    Config: Config,

And I test it like so:

// test.js: 

const index = require('../index');

let config;

describe('config ', () => {
    before(() => {
        config = new index.Config().get();

It works, but I'm wary of including a capitalized property in module.exports (mostly because I haven't seen this done before). Is there a best practice for achieving this in other ways? Should I just make the config class into its own .js file?

  • 1
    \$\begingroup\$ Yes the simple rule is capitalised if the function requires the new token to correctly instantiate. Though I would argue that best practice avoids the use of the new class token altogether. Also don't use the prototype to store static values. \$\endgroup\$
    – Blindman67
    Dec 2 '16 at 17:41

I'm not aware of any best practice here, so this answer is my own hunch.

I would stick with using an uppercase 'C' for the exported member name.

In JavaScript, the usual protocol is to use an uppercase name for a function that should be new from, rather than called directly e.g.

function Config()

to show that the function should be used with a new call, to treat it as a constructor. e.g.

var config = new Config();

As you are exposing a class from your module, in other words a function that can be new'd up from, then I would stick with using a capital C.


It works, but I'm wary of including a capitalized property in module.exports

This is perfectly fine. By convention, constructors and classes use TitleCase, where the first letter in a multi-word name is uppercase while the rest is lower case. Anything else, like variables and functions use camelCase.

Since Config is a class, then it makes sense to do so.

Should I just make the config class into its own .js file?

That depends on preference and use of the module's functionality. In some cases, it makes sense to export just one thing. That way, one file, one responsibility. However, in some cases, you might want to treat modules as a collection of functions.

Both ES6 modules and CommonJS modules do not impose strict rules as to how you export.

  • \$\begingroup\$ Config is not a class, it is an object definition. There is no such thing as a class in Javascript. class loosely refers to an object construction syntax. \$\endgroup\$
    – Blindman67
    Dec 2 '16 at 19:26
  • \$\begingroup\$ @Blindman67 "class loosely refers to an object construction syntax." - which I just did. And I used it to make it distinct from a constructor function that essentially does the same thing, written differently, and which by convention also uses TitleCase. \$\endgroup\$
    – Joseph
    Dec 2 '16 at 19:47
  • 1
    \$\begingroup\$ I am pointing it out to emphasize that class is syntax in JavaScript and that we should be careful not to infer a paradigm that does not exist. Though to me i am surprised that a "use strict" directive would not enforce "TitleCase" when using class as it does make it clear. But then who are we to define nomenclature \$\endgroup\$
    – Blindman67
    Dec 2 '16 at 20:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.