sanctuary-js / sanctuary-type-identifiers Goto Github PK

I get an error while using js-yaml lib with sanctury's encaseEither function:

const { safeLoad } = require('js-yaml');
const parseYaml = encaseEither(I, safeLoad);
parseYaml('Some invalid yaml');

Here what i get:

TypeError: Invalid value

encaseEither :: (Error -> l) -> (a -> r) -> a -> Either l r
                 ^^^^^
                   1

1)  YAMLException: end of the stream or a document separator is expected at line 2, column 8:
      redis:
           ^ :: Object, StrMap ???

The value at position 1 is not a member of ‘Error’.

YAMLException defined as MDN recommends in its examples: https://github.com/nodeca/js-yaml/blob/master/lib/js-yaml/exception.js and MDN examples https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Error#Custom_Error_Types

type determines YAMLException as Object, and thats looks wierd

My runtime is node 8.1.3

When using Sanctuary-Type-Identifiers to determine whether something is member of a specific desired type, we get a nice advantage: Even if the value was created in a different context (like in another VM or another package), it will still be identifiable as being our type.

However! When the type was created by an outdated package, we currently have no way to tell that this is actually not the desired type, when using the recommended format for @@type (<vendor>/<type>).

I've therefore been thinking to add a version number to my @@type values (eg <vendor>/<type>@<major>). This would allow my type-checks to detect "older" versions of my type, which may no longer satisfy the interface I expect them to have. And it works both ways: An older version of my lib will not try to consume a newer version of its own type.

Is this something you would stand behind @davidchambers? Or does this somehow go against the purpose of @@type?