Hypothetical situation, I have 3 node modules all native, A, B, and C. 

  • A is a utilities module which exposes several functions to javascript through the node interface, in addition it declares/defines a rich set of native structures and functions
  • B is a module which is dependent on data structures and source in A, it exposes some functions to javascript, in addition it declares/defines native structures and functions
  • C is a module which is dependent on data structures and source in A & B, it exploses some functions to javascript, in addition it declares/defines native structures and functions

So far when setting up these modules I have a preinstall script to install other dependent includes, but in order to access all of another modules source what is the best way to link to it's share library object (*.node) ?

Is there an alternative best practice for native modules (such as installing all source from other modules before building that single module)? Reply


2 Answers 2


There are essentially two ways to do this. Which one is suitable for you depends on what you want to accomplish.

  1. Case 1: A, B and C are loosely related, that is if e.g. B can be used without A and C. Having A and/or C available would extend the functionality of B.

  2. Case 2: A, B and C are tightly related and some part of A, B or C relies on the existence of A, B or C. Together they form a logical unit.

If Case 1 fits your projects' purpose, then you want to build separate node modules and have the end user pull in those modules and use them at will.

If Case 2 fits better, then you want to compile A, B and C into one module e.g. ABC. You can still structure the source code (and exported API) of the ABC module according to A, B and C.

Building three separate modules and linking them dynamically makes little sense. In fact, they are dynamically linked (by node) when imported (require'd) in node-land. Linking them together statically might make more sense, bus is essentially just a messier way of accomplishing "solution 2" (producing a single module).


If A, B and C are three modules that are not authored by you, then you are dealing with a hierarchy. As you explain it in your hypothesis, the hierarchy of dependance is:

B --requires--> A
C --requires--> B
C --requires--> A

Thus A could be "owned" by B, and B could be owned by C. If you author C, then provide a user-facing API with an entry-point in JavaScript, where you require the three modules. Compile A, B and C as separate modules and have them live "inside" your compound module. The file system structure could look something like this:

foo/          # Your compound module
foo/index.js  # require('./_A'), require('./_B'), require('./_C')

As the code in _C.node requires certain symbols to be implemented (i.e. the depending symbols from A and B), you will need to load the modules in order.

Note that I have not tested this, but in theory, this should work.

  • 1
    This slightly old node.js native module is structured like the third suggestion, where the native module(s) (in this case only one) are packaged inside a compound module. github.com/liesen/libspotify-node/blob/master/spotify/index.js
    – rsms
    Commented Jun 25, 2012 at 23:12
  • much appreciate your contribution rsms, just shared what I'm going with now (basically submodules and conditional compiles). The reason I went this route is that going with npm/module caused most of the internal structures to be inaccessible between modules (aka C and B couldn't access all the native methods/functions of A). They could access/call include file only methods/functions
    – Mark Essel
    Commented Jun 27, 2012 at 14:14

Prompted by rsms I'd like to share the architecture I'm going with now originally answered/shared here on stackoverflow.

What's the best way to create common native source code packages that other node modules can rely on?

...I do have an answer for constructing reusable libraries witlinh native node modules.

I'm using git submodules for all the independent native node modules, and added a conditional preprocessor definition for each of their wscript or binding.gyp files to specify whether or not to generate a shared object .node module.

In addition I'll be using this new package to aid in debugging or rewriting code sections (I can't spend too much time debugging utilization of several remote libraries).

in wscript or binding.gyp

  flags = ['-D_NAME_NODE_MODULE', '-O3', '-Wall', '-D_FILE_OFFSET_BITS=64', '-D_LARGEFILE_SOURCE', '-msse2']

then in an initialization file


extern "C" {
  static void init(Handle<Object> target) {
    HandleScope scope;
    NODE_SET_METHOD(target, "someFunction", someFunction);

  NODE_MODULE(moduleName, init);


This way a node native module is only added to when the flag is set. Otherwise it can be linked to normally (like in another node module).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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