rttc - npm Package Compare versions

Comparing version 9.8.2 to 10.0.0-0

lib/parse-human.js

@@ -8,3 +8,2 @@ /**
 var types = require('./helpers/types');
-var coerce = require('./coerce');
 var validate = require('./validate');
@@ -19,7 +18,13 @@ var parse = require('./parse');
  * Convert a string that was entered by a human into a value of the appropriate type.
- * If optional type schema is provided, use it to make a better guess.
- * Additionally, if type schema is provided, it will be used to coerce the result.
+ * By default, parse numbers and booleans-- but otherwise leave it as a string.
  *
- * > Non-primitives (like dictionaries & arrays) will not undergo full coercion, so as of
- * > rttc@9.8.1, this is still experimental and so should not be relied upon!
+ * On the other hand, if the optional `expectedTypeSchema` is provided, use it to make a better guess:
+ *   • If the type schema is expecting a string, number, or boolean, then loose validation (`rttc.validate()`)
+ *     will be performed and the potentially-coerced result will be returned.
+ *   • If the type schema is expecting a function, then if `unsafeMode` is enabled, the human string will be hydrated
+ *     as a JavaScript function.  Otherwise, if `unsafeMode` is false, an error will be thrown.
+ *   • Finally, if the type schema is expecting a dictionary, array, JSON, or any ref, then interpret the human string
+ *     as JSON (using rttc.parse(), with respect for `unsafeMode` re hydrating nested functions).  If the string cannot
+ *     be parsed as JSON, an error is thrown.  But if the rttc.parse() is successful, the result is then validated against
+ *     the type schema (using RTTC loose validation).  If _that_ doesn't throw an error, then the result is returned.
  *
@@ -34,3 +39,3 @@ * @param  {String} humanString
   if (!_.isString(humanString)) {
-    throw new Error('rttc.parseHuman() expects a string value, but a '+typeof humanString+' was provided:'+util.inspect(humanString, false, null));
+    throw new Error('rttc.parseHuman() expects a string value, but a '+typeof humanString+' was provided: '+util.inspect(humanString, false, null));
   }
@@ -42,2 +47,3 @@
 
+
   // If no type schema was specified, we will try to make a nice number or boolean
@@ -57,8 +63,14 @@ // out of the value, but if that doesn't work, we'll leave it a string.
 
-  // If the type schema is expecting a simple string, boolean, or number,
-  // just coerce it and send the result back.
+
+  // --•
+  // A type schema was specified.
+
+  // If the type schema is expecting a simple string, boolean, or number, then...
   if (expectedTypeSchema === 'string' || expectedTypeSchema === 'number' || expectedTypeSchema === 'boolean') {
-    return coerce(expectedTypeSchema, humanString);
+    // Run the string through RTTC loose validation. and send the result back.
+    // (if validation fails, an error will be thrown)
+    return validate(expectedTypeSchema, humanString);
   }
 
+  // --•
   // If the type schema is expecting a simple lamda function, attempt to use hydrate.
@@ -71,5 +83,7 @@ // (but if `unsafeMode` is disabled, just return the string as-is)
 
+  // --•
   // Otherwise, we'll assume this was entered as JSON and parse it first...
   // ...and if we make it past that, then we'll validate (and potentially lightly coerce) the final result.
   return validate(expectedTypeSchema, parse(humanString, expectedTypeSchema, unsafeMode));
+
 };

package.json

 {
   "name": "rttc",
-  "version": "9.8.2",
+  "version": "10.0.0-0",
   "description": "Runtime type-checking for JavaScript.",
@@ -5,0 +5,0 @@ "main": "index.js",

README.md

@@ -645,3 +645,3 @@ # RTTC
 >
-> So even though `parseHuman()` is quite forgiving (it uses `rttc.coerce()`), you can rest assured that _any_ string you
+> So even though `parseHuman()` is quite forgiving (it uses RTTC loose validation), you can rest assured that _any_ string you
 > generate using `stringifyHuman()` will be properly deserialized by `parseHuman()`, provided it is passed in with the same type schema.
@@ -648,0 +648,0 @@

New alerts

No v1

Quality

Package is not semver >=1. This means it is not stable and does not support ^ ranges.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

283548

increased by0.25%

Lines of code

5559

increased by0.18%

Worsened metrics

Number of package files

50

decreased by-1.96%

Number of low quality alerts

2

increased by100%

No dependency changes