> If you stick to this, you'll always be injecting implementations You could make abstract classes with error-throwing methods, then extend from those for the

> If you stick to this, you'll always be injecting implementations You could make abstract classes with error-throwing methods, then extend from those for the implementation. I think most Node people would think of that as extra boilerplate, though, since DI in Node frameworks usually exists as a side effect of other technical requirements rather than as a design goal in its own right.