node: how to require different classes depending on env

Question

In node, module imports (aka require()) are hard coded in every file (aka module) which requires that import. This is can be tens or in our case hundreds of duplicate imports. What we are "requiring" in a dynamic way are mainly services, e.g. "playerService" with find, update, get methods etc. but could also be domain objects or persistence libraries

The crux is we have 3 versions of this "playerService" js file. One which does everything locally (in memory) for development, one which does everything with a local database (test), and one which does everything with an external system via an API (live). The switch in this case in on environment (dev, test or live).

It is worth noting we use classes everywhere we can because we find functions which return functions of functions etc. to be unreadable/maintainable (we are java developers really struggling with js)

We are also exclusively using web sockets in our node app -there is no http code.

So our services look like this:

const Player = require("./player")
class PlayerService {
  constructor(timeout) {
     this.timeout= 3000  // todo, put in a config file
     if (timeout != null) {this.timeout= timeout}
  }
  updatePlayer(player) {
     // logic to lookup player in local array and change it for dev version.
     // test version would lookup player in DB and update it.
  }
}
module.exports = PlayerService

We are familiar with dependency injection with Grails and spring, but haven't found anything comprehensible (see below) for node. We are not javascript nor node gurus unfortunately, despite extensive reading.

Currently we are considering one of these options, but would like to hear any better suggestions:

option 1:

1. Hard code the "dev" requires, e.g. require("./dev/playerSerice")
2. have a jenkins build server rewrite the source code in every file to require("./test/playerSerice").

option 2:

1. Hard code the "dev" requires, e.g. require("./playerSerice")
2. have a jenkins build server swap the file /test/playerService/playerService" to ./playerService.

Obviously these make it hard for developers to run the test or pro versions on their local machines without hacking the source.

option 3: 1. put the required module paths in a single config file. 2. swap out just the config file. E.g.

let Config = require("./config")
let PlayerService = require(Config.playerService)

We have tried to make this dependent on env and have a global config which the development, test and prod configs over ride these, but have not found an elegant way to do this. One way might be to duplicate this code at the top of every module:

let env = process.env.NODE_ENV || 'development'
let config = require('./config.'+env);
let PlayerService = require("./" + Config.playerService)

Then in config.development.js:

var config = require("./config.global")
config.PlayerService = "devPlayerService"
module.exports = config

Option 4: Perhaps something like this would work:

let env = process.env.NODE_ENV || 'development'
require("./" + env + "/playerService")

all the above solutions suffer from lack of singletons - services are stateless. We are guessing that node is going to construct a new copy of each service for each request (or web socket message in our case). Is there a way to minimise this?

Obviously some simple, readable, and officially maintained form of Dependency injection would be nice, with some way to switch between which set of classes were injected.

We have read the following posts:

1. https://blog.risingstack.com/dependency-injection-in-node-js/ resultant code is unreadable (for us at least). The example being so contrived doesn't help, team is just some sort of proxy wrapper around User, not a service or anything useful. What are options? Why options?
2. https://medium.com/@Jeffijoe/dependency-injection-in-node-js-2016-edition-f2a88efdd427

But found them incomprehensible. E.g. the examples have keywords which come from thin air - they dont seem to be javascript or node commands and are not explained in the documentation where they come from.

And looked at these projects:

1. https://github.com/jaredhanson/electrolyte
2. https://www.npmjs.com/package/node-dependency-injection
3. https://www.npmjs.com/package/di

but they seemed to be either abandoned (di), not maintained or we just cant figure them out (electrolyte).

Is there some standard or simple di solution that many people are using, ideally documented for mortals and with a non "express" dependent example?

UPDATE 1

It seems the pattern I am using to create my services creates a new instance very time it is used/called. Services should be singletons. The simple solution is to add this to the bottom of my services:

let playerService = new PlayerService();
module.exports = playerService;

Apparently, this only creates one instance of the object, no matter now many times require("./playerService") is called.

Answer 1

For keeping the configuration per env, the right way is probably (similar to what you suggested)- Keeping a config/env directory and putting there a file per env, ie development.js, test.js etc, and in each of them putting the right values. eg:

module.exports = {
   playerService: 'dev/PlayerService'
}   

and require it:

let env = process.env.NODE_ENV || 'development'
, envConfig = require("./config/" + env)
, playerService = require(envConfig.playerService)

You can also have the all in one file like this: config.js:

module.exports = {
    development:{
        playerService: '....'
    },
    test:{
        playerService: '....'
    }
}

and require it:

let env = process.env.NODE_ENV || 'development'
, config = require("./config")
, playerService = require(config[env][playerService])

This is a common use-case.

Or, if you have all services in directories per env, ie one directory for dev, one for test etc, you don't need the config, you can require like that:

 let env = process.env.NODE_ENV || 'development'
, playerService = require('./' + env + '/playerServcie')  

Making the services singleton in node js should be simple, have a look at the following:

https://blog.risingstack.com/fundamental-node-js-design-patterns/

https://www.sitepoint.com/javascript-design-patterns-singleton/

and this

Hope this helps.