[x] add substack's resolve module to make sure we follow the node resolve/resolution algorithm the same as node's built-in require would. We're using resolve.sync because quibble's API was already sync despite doing file I/O (as require itself is), we're also trapping exceptions b/c non-existent unresolvable paths are to be expected
[x] when creating a stubbing & absolutifying the given path, also run it through resolve.sync to see if there's an existing file that node would, at-that-point, match (and if so, key off that would-be resolved file). This could conceivably break people who create module files on disk after quibbling but before asserting, but I really hope no one does that. This will keep completely non-existent paths working while making existent require'd paths resolvable
[x] change stubbing search from exact-string-match to: (1) required-path-exactly matches resolved stubbing path, (2) resolved-required-path matches resolved stubbing path, (3) stubbing path was not resolvable but the required-path matched it exactly
[x] gross: use lodash's non-fp find alongside the fp-find (i named it ooFind), because fp/find will cap the iterator to one arg, and I needed the key.
[x] add a bunch more tests as my self-esteem & confidence dropped through the floor.
These changes should result in a minor performance hit for existing uses of quibble (there are n more resolve() calls each time a stubbing is set up). New tests going forward that take advantage of this flexibility (like the one given in #16) will also rack up an additional resolve() call per require of a stubbed path, which could potentially really add up over the course of a test suite.
In the end, I think correctness is more important than speed in this case. Eager for faster alternatives that would still be as correct.
WIP. Fixes #16
requirewould. We're usingresolve.syncbecause quibble's API was already sync despite doing file I/O (asrequireitself is), we're also trapping exceptions b/c non-existent unresolvable paths are to be expectedresolve.syncto see if there's an existing file that node would, at-that-point, match (and if so, key off that would-be resolved file). This could conceivably break people who create module files on disk after quibbling but before asserting, but I really hope no one does that. This will keep completely non-existent paths working while making existentrequire'd paths resolvableooFind), because fp/find will cap the iterator to one arg, and I needed the key.These changes should result in a minor performance hit for existing uses of quibble (there are
nmoreresolve()calls each time a stubbing is set up). New tests going forward that take advantage of this flexibility (like the one given in #16) will also rack up an additionalresolve()call perrequireof a stubbed path, which could potentially really add up over the course of a test suite.In the end, I think correctness is more important than speed in this case. Eager for faster alternatives that would still be as correct.