re: Why I struggle with Node VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Mocking modules can be done in a number of ways, but almost all of them seem to work on the require calls. Using ES6 means that you use import stat...
 

Regarding DI, node modules are already basically a service locator, so you don't really need it. Definitely not for testing anyway.

Proxyquire does need some ES6/babel/typescript love, I agree, but its just a matter of looking at the compilation output of babel and setting up the mocks accordingly. Would be nice if there was direct support for it. Sounds like a good pull request or module :)

TS largely solves the 3rd party library problem of flow. The number of available type definitions is quite impressive: npmjs.com/~types

I second the recommendation for VSCode. Don't know if it solves all your debugging troubles though. A lot of the problems with mocha come from it not playing well with other tools unless you use the _mocha binary, since mocha itself likes to start _mocha as a subprocess IIRC

The DI needs are a lot more than just Service Locator though. It is all about abstracting away the wiring of your modules. It means that you can change the service that a module depends on simply by changing the wiring, and not changing the module itself. And that instantly means that the modules have to depend on the API of the service, not the implementation.

Regarding Proxyquire or similar, that would work but it means doing the imports in the middle of your tests - which is, of course, how Node does these things. That goes against the idea from ES6 that imports are done before any code, and simply set up the scene for your code to work.

code of conduct - report abuse