5 ms·

Out of interest: What was the context where you needed the validation? In most contexts, the reasonable approach would be to only do runtime validation at your

• throwanem 6y ago
  The case I mentioned didn't have to do with validation - in a case like that, I would have used a type guard, or more likely a runtype. This was a Javascript corner case that I hadn't previously encountered, where if you load the same module from two different paths, they aren't `instanceof`-equivalent. In this case, both the codebase of a module I was working on, and the codebase of one of its consumers, imported the same module from the same package, and I ran into the issue when I `npm link`-ed the module into its consumer's node_modules dir for testing and to ensure I hadn't inadvertently broken an implicit contract. The `instanceof` mismatch, between an object instantiated in module code and the class imported by the consumer, confused the type system and gave me spurious errors as a result. Thinking about how to solve this, it occurred to me to use a type guard, since it would have effectively convinced the type checker that my object instance was in fact an instance of the class of which it is an instance. But it would've been a wart and also imposed the aforementioned runtime overhead - not that that would've been meaningful in this case, it wasn't in a hot loop or anything, but I still didn't like it. So I ended up instead exporting the shared dependency from the module and having the consumer import it from there, rather than from its own (IIRC otherwise unused and thus eliminated) copy of the shared dependency.