search

clux / logule

A multi-transport, peer-dependent logging library for nodejs - UNMAINTAINED
MIT License
35 stars 5 forks source link

Implicit Dependency Injection #12

Closed clux closed 11 years ago

clux commented 11 years ago

I just committed a bunch of code that allows you to do implicit dependency injection.

Explicit DI was problematic at module borders because injecting your own logule instance should typically be an optional step, resulting in the same boilerplate stuff everywhere, and races if this was not done in the beginning. Thus, it felt sub-optimal and here's an attempt to improve it.

Consider a setup looking like this:

a.js
└──┬b.js
   └───c.js

and all three files initialize their logger with var log = require('lodule').init(module), before requiring its other children. Logule is now able to utilize the previous init data so that namespaces/suppressions from one file propagate to the next without the need for explicit DI. See the updated readme for a nice example of this.

This is possible with just local variables in logule because multiple require calls to the same physical file is cached in node.

Now a problem arises with multi-copy installations (i.e. relying on modules that bundle logule by default). The second physical copy of logule will thus try to build its own tree from its entry point and will be insuppressible (at least by branch).

It is possible to make these cooperate in a couple of ways.

  1. Store the tree on the global object or on process if possible and have both copies read from it.
  2. Encourage using '"logule":"latest" in package.json and rely on npm dedupe
  3. Emulate 2 by manually link installing logule and going through dependencies, potentially notifying laggards.

Second way does not guard against new releases and I would have to manually notify owners. I plan to stabilize the API anyway, but you can never truly tell with software.

Third way is non-intrusive, but will perhaps leave branch filtration non-workable for a period of time after every release and requires more advanced use of npm.

First way breaks encasulation, any rogue module could mess with the tree. Versioning is less of an issue as I'm much less likely to change just the way data is stored (and though I could always semver guard there as I used to do with .verify(), this seems overkill).

So that's the dilemma at the moment. Perhaps there are other ways I haven't considered, but for now I will not push a version to npm until this is decided. You can experiment with the code base from master though.

clux commented 11 years ago

It helps to write these things down, if just for yourself.

I'll extend process (rather than global) with a logule var that keeps track of the namespaces/suppressed types. The multiple logule communication API will be frozen from the next version ensuring no versioning mishaps mess up potential future versions.