Message from JavaScript discussions

November 2020

— It's fine to directly depend on such dependencies, since they won't reduce testability

— 

We found that out too. In our private discussion we only injected their own code. They wanted to make everything a singleton. I would prefer to make everything flexible, and only in the root of the module create one instance and export that one.

— Regarding TS, I'd also add that since TS has structural typing, it's possible to avoid relying on types by identity in tests, so you can rely only on the "shape" of your dependency being correct, rather than the exact dependency required for production, and forcing you to do some hacky type stuff during testing

Message permanent page

— (Example: Have functions that take "thenables", and not "*THE* global Promise instance")

— I agree with your method

— I am still struggling a little bit with fitting exact dependencies into tests..

— Like, the original function requires the entire fs when the underlying module only needs.. say fs.writeFile and fs.readFile

Message permanent page

— Basically, when you pass an argument to a type in TypeScript, TypeScript can compare their shapes rather than their identity

Message permanent page

— Do I always have to Pick<> then?

— So in this case, you can do something like:

{ readFile: (path: string, enc: string) => string & (path: string) => Buffer }

(which granted is quite a big signature, BUT it grants you the ability to provide only the API your function needs, and not the entire fs library)

Message permanent page

— Another cool benefit is that if node stdlib has breaking changes, you can detect if your functions are affected by it, since TS will actually compare the structures

Message permanent page

— 🤔 okay