JS dependency injection container

Round 2 of my “global namespace” thoughts. @wh0 I’d like your input on this. Again I’m using a logger but this isn’t about logging.

I have two versions one “normal” and one that “colorizes”, both are simple modules not classes so there is no Singleton stuff going on. Depending upon which module needs the logger (as is always the case) the path to the logger will be slightly different. More importantly there is a direct path to the logger so changing from the normal to the colorized one means I have to modify const logger = require() code in every module using the logger.

So how do you feel about a di container module? This can be set up in the startup and a logger instance supplied at that time. Any other module would require the diContainer.js and get a reference to the logger it has. It could contain a reference to a DB if needed as well. The app logger is set up at startup, any module can get to it and there is an explicit require statement so there is no magical appearance of (in this case) a logger.

What do you think?

that sounds like a pretty normal way to do it. I’ve seen various other logging packages for other languages do it that way.

Thanks I went ahead an implemented it that way, a simple servicesSvc that modules can request the services it needs from. I like it.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.