Add testValue API

index.js

@@ -8,6 +8,7 @@ module.exports = {
 	validateArguments: require("./src/api/validate-arguments"),
 	validateOptions: require("./src/api/validate-options"),
 	validateValue: require("./src/api/validate-value"),
+	testValue: require("./src/api/test-value"),
 
 	AggregrateValidationError: require("./src/aggregrate-validation-error"),
 	RemainingArguments: require("./src/api/validate-arguments/remaining-arguments-symbol")

src/aggregrate-errors.js

@@ -19,6 +19,7 @@ function joinPathSegments(segments) {
 		: "(root)";
 }
 
+// FIXME: Render error codes (grayed out) after error messages, as a stable identifier
 function renderErrorList(errors, subErrorLevels = 0) {
 	let rephrasedErrors = errors.map((error, i) => {
 		let pathSegments = error.path.map((segment) => {

src/api/test-value.js

@@ -0,0 +1,12 @@
+"use strict";
+
+const applyValidators = require("../apply-validators");
+
+// NOTE: This will *not* give you access to either the errors or the transformed value! It's typically used for conditional logic in business logic *after* the initial validation has already taken place. This allows for reusing the entire ecosystem of Validatem validators for "does this value match format X, if yes, run this code"-type logic.
+// FIXME: Put this in the documentation instead.
+
+module.exports = function (value, rules) {
+	let { errors } = applyValidators(value, rules);
+
+	return (errors.length === 0);
+};

src/api/validate-arguments/index.js

@@ -17,6 +17,7 @@ const RemainingArguments = require("./remaining-arguments-symbol");
 // TODO: Simplify below by treating it like an array or object? Or would that introduce too much complexity through specialcasing?
 // TODO: Find a way to produce validatem-style errors for the below invocation errors, without introducing recursion
 // TODO: Maybe create a validatedFunction(rules, (foo, bar) => ...) type abstraction for "pre-processed", more performant validation usecases? At the cost of having to specify the validation rules outside of the function, which you'd need to do anyway in that case. Upside would be that you don't need to specify `arguments` manually anymore.
+// TODO: Special-case callsite extraction from stacktrace when using validateArguments, as the user will probably be interested in where the validator-fenced code was *called from*, not where the rules are defined (unlike with validateValue)
 
 function arrayToNormalized(array) {
 	return array.map((definition) => {

src/colors.js

@@ -16,8 +16,8 @@ if (supportsColor.stderr) {
 } else {
 	openHighlight = "";
 	openDim = "";
-	openHighlightBold = ""; // cyan bold
+	openHighlightBold = "";
-	openDimBold = ""; // gray bold
+	openDimBold = "";
 	closeColor = "";
 }
 

src/compose-rules.js

@@ -70,6 +70,7 @@ module.exports.compose = function composeValidators(validators) {
 	}
 
 	return function composedValidator(value, context) {
+		// FIXME: Does this still need to be a special case, now that we have the callIfNull property?
 		if (isRequired && value == null) {
 			return validationResult({
 				errors: [ new ValidationError(`Required value is missing`) ],