Michael Petrochuk Michael Petrochuk - 2 months ago 6x
Javascript Question

Node ES6: class is not a function

I am trying to figure out a bug that i've been running into in my code. I wrote out a simple example that replicated the bug using classes a, b and a entry file c.

Where is my code going wrong?


Many of the answers are concerning my code structure! I would like to clarify the functionality that is required.

  1. a: needs a static instance of b. Therefore, A needs to require B.

  2. b's functions (none static): only accept objects that are an
    instanceof a
    . Therefore, B needs to require A.

Specifically, I have a "Phrase" class (a) and a "Parser" class (b). Parser only accepts phrases. Phrase parses its self on creation using its static parser instance.


'use strict';

let b = require('./b.js');

class a {
constructor() {


new b();

module.exports = a;


'use strict';

let a = require('./a.js');

class b {
constructor() {


module.exports = b;


'use strict';

let b = require('./b.js');
new b();

node c.js


new b();

TypeError: b is not a function
at Object.<anonymous> (C:\code\projects\elegance\data-frog\tag\datastructures\a.js:11:7)
at Module._compile (module.js:413:34)
at Object.Module._extensions..js (module.js:422:10)
at Module.load (module.js:357:32)
at Function.Module._load (module.js:314:12)
at Module.require (module.js:367:17)
at require (internal/module.js:16:19)
at Object.<anonymous> (C:\code\projects\elegance\data-frog\tag\datastructures\b.js:3:9)
at Module._compile (module.js:413:34)
at Object.Module._extensions..js (module.js:422:10)



Based upon your edit, my immediate suggestion is that you continue to use class Phrase if you choose to keep it, specifically because you like having the ability to log the type of an object...
...but to use that constructor as nothing more than a struct that you would find in other languages.

Your Parser can know about Phrases, given that it parses them, but there's really 0 harm in having the parser accept duck-typed entries, as the difference in flexibility is large, if you check for the interface your method wants (fields on the struct that you actually use), versus checking for a strict instance.

A quick example may be loading a list of phrases from a web service. Do you really need to instantiate every line as a phrase, before parsing them?

Here's an example of how you might handle the case in which you have a low-level struct, which doesn't really need a factory for DI (because it's so low-level), but rather, could be directly imported into the Parser module.

// phrase.js
class Phrase {
  constructor (content = "") {
    this.content = content;

  static from (phrase) {
    return new Phrase(phrase.content);

  static isPhrase (phrase) {
    return phrase && phrase.content !== null && phrase.content !== undefined;

export default Phrase; // or module.exports

// parser.js
import Parser from "./parser"; // or require, whatever floats your boat
class Parser {
  static parse ( input = "" ) {
    const preparedContent = Phrase.isPhrase( input )
      ? Parser.prepareContent( input.content )
      : Parser.prepareContent( input );

    return new Phrase(content);

  static prepareContent ( input = "" ) {
    // ...

  parse (content) {
    return Parser.parse(content);

export default Parser;

I can now make an instance of Parser or just statically use it.
I can hand it raw input, or I can hand it a Phrase, and it will do the right thing.
Moreover, I'm not relying on Parser to be able to define what Phrase is. Parser is relying on a Phrase builder to know what Phrase is.

Parser is always returning a new instance of a "parsed" Phrase, but its input is now more relaxed. As well, based on what is coming in, you can now do more-sane things with your input (ie: provide good defaults, like safely returning an empty phrase (where phrase.content in my example world might be an empty string), rather than returning null or throwing, based on an instanceof).

Have a look at an answer which I provided elsewhere, for further details (and check the question to see where he hit a similar roadblock exactly one stop beyond where you are, currently).

ES6 modules and inheritance

The answer, though, is that you should not be relying on circular dependencies, which will do terrible, terrible things to your codebase.

If you really, really, well and truly need to do this (you don't), you should be using a Factory to ensure that the correct instances are built/used, and injecting the factory into your application, rather than the classes themselves.

If you are seriously depending, wholesale, upon the typeof or instanceof functionality to ensure the sturdiness of your application -- especially in such a way that the check requires circular references, then your application is not sturdy in the first place

Your classes should not need to know about one another, and when you delegate their construction to factories, if that's the path you choose to take, then the classes should not know about the factory, either.