
Security News
New React Server Components Vulnerabilities: DoS and Source Code Exposure
New DoS and source code exposure bugs in React Server Components and Next.js: what’s affected and how to update safely.
validate-all-types
Advanced tools
validate-all-types?This package is a type validator mainly for Typescript (also works with Javascript). Ever faced those issues where you're trying to make sure a type any is an instance of an interface? This is the issue this package was designed to solve. With this package, you can safely assert the type for an object and return customised errors if the types are incorrect
$ npm install validate-all-types
or
$ yarn add validate-all-types
then import the module like this:
// Typescript
import { Check, ... } from "validate-all-types"
// Javascript
const { Check, ... } = require("validate-all-types")
Typescript typings are automatically included so there's no need to install anything like @types/validate-all-types !
The Check object we imported earlier is a function which can take 2 (3: optional) parameters.
| Number | Type | Description |
|---|---|---|
| 1 | any | The object we are checking |
| 2 | ITpattern | A specific pattern to compare the object to (more about this later) |
| 3 | string? | The name of the root object when logs display errors. Defaults to * as root |
The type ITpattern is something you don't need to worry about. Just know that it is the Typescript type for a pattern. Patterns can look like Tstring() or Tnumber(). Because there are quite a few Patterns, we will generalise them by calling them T{type}() functions
| Index | Type | Description |
|---|---|---|
| 0 | boolean | Whether the validation of the object was a success or failure. true if success, false if failure |
| 1 | string[] | The list of corrections to make if any |
There are infinite combinations of patterns we can make. The complexity of the pattern only depends on how much code you are willing to write.
Because you have no idea how T{type}() functions works, I will use the string example to teach you exactly how the T{type}() functions work in full detail so this first chapter may be a bit long winded... All the T{type}() functions are importable from the module
Here is how to validate a string
console.log(Check("string", Tstring()))
// > [ true, [] ]
console.log(Check(0, Tstring()))
// > [ false, [ '*: Expected (*) to be of type `string`' ] ]
Notice that in the error message, the root element is called * because as mentioned earlier, if we don't pass a third parameter into the Check() function, it names the root * by default.
The function Tstring with nothing in the parameters represents a Type string (T for type and string for string, therefore: Tstring). This method can also take in items in the parameters:
| Type | Description |
|---|---|
| (empty) | Checks if the input is a string |
| RegExp | Checks if the input is a string and matches the RegExp |
| ...string[] | Checks if the input is a string and matches any of the given strings |
import { Check, Tstring } from "validate-all-types"
console.log(Check("string", Tstring()))
// > [ true, [] ]
// This returned true because "string" is a string
console.log(Check(0, Tstring()))
// > [ false, [ '*: Expected (*) to be of type `string`' ] ]
// This returned false because 0 is not a string
console.log(Check("string", Tstring(/^string$/)))
// > [ true, [] ]
// This returned true because "string" matches the RegExp /^string$/
console.log(Check("string", Tstring(/^something-else$/)))
// > [ false, [ '*: Expected (*) to match RegExp (/^something-else$/)' ] ]
// This returned false because "string" didn't match the RegExp /^something-else$/
console.log(Check("string", Tstring("does", "the", "string", "match", "?")))
// > [ true, [] ]
// This returned true because "string" was passed into Tstring() as a parameter
console.log(Check("string", Tstring("doesn't", "match"), "my-string"))
// > [ false, [ `my-string: Expected (my-string) to be in (["doesn't","match"])` ] ]
// This returns false because "string" wasn't passed into Tstring() as a parameter
// Since I passed a third parameter to the Check function, the root got renamed
Whew! That was quite a steep learning curve... Now since you already know the basics of how Check() and Tstring() works, it should be much easier from here on
Tnumber()Because Tstring() validates strings, it's obvious that Tnumber() validates numbers. Tnumber() works the same was as Tstring() except allows a different set of parameters:
| Type | Description |
|---|---|
| (empty) | Checks if the input is a number |
| ...number[] | Checks if the input is a number and matches any of the given numbers |
import { Check, Tnumber } from "validate-all-types"
console.log(Check(3, Tnumber()))
// > [ true, [] ]
console.log(Check("string", Tnumber()))
// > [ false, [ '*: Expected (*) to be of type `number`' ] ]
console.log(Check(3, Tnumber(1, 2, 3, 4, 5)))
// > [ true, [] ]
console.log(Check(3, Tnumber(6, 7, 8, 9, 10)))
// > [ false, [ '*: Expected (*) to be in ([6,7,8,9,10])' ] ]
Tboolean()Tboolean() allows comparison of booleans only
| Type | Description |
|---|---|
| (empty) | Checks if the input is a boolean |
| boolean | Checks if the input is a boolean and if the booleans are equal |
import { Check, Tboolean } from "validate-all-types"
console.log(Check(true, Tboolean()))
// > [ true, [] ]
console.log(Check("string", Tboolean()))
// > [ false, [ '*: Expected (*) to be of type `boolean`' ] ]
console.log(Check(true, Tboolean(true)))
// > [ true, [] ]
console.log(Check(false, Tboolean(true)))
// > [ false, [ '*: Expected (*) to be `true`' ] ]
Tnull()Tnull() doesn't allow variations of the parameters
| Type | Description |
|---|---|
| (empty) | Checks if the input is a null |
import { Check, Tnull } from "validate-all-types"
console.log(Check(null, Tnull()))
// > [ true, [] ]
console.log(Check(undefined, Tnull()))
// > [ false, [ '*: Expected (*) to be of type `null`' ] ]
Tundefined()Just like Tnull(), Tundefined() doesn't allow variations of the parameters
| Type | Description |
|---|---|
| (empty) | Checks if the input is a undefined |
import { Check, Tundefined } from "validate-all-types"
console.log(Check(undefined, Tundefined()))
// > [ true, [] ]
console.log(Check(null, Tundefined()))
// > [ false, [ '*: Expected (*) to be of type `undefined`' ] ]
Tlist()This one's a bit more complicated. Tlist() allows a few sets of parameters:
| Type | Description |
|---|---|
| (empty) | Checks if the input is a list |
| ...ITPattern[] | Checks if the input is a list and checks if all items in the list match at least 1 of the Patterns stated |
You can put in T{type}() functions as parameters for Tlist() so as to do stricter checking of types
import { Check, Tlist, Tstring, Tnumber } from "validate-all-types"
console.log(Check([1, 2, 3, 4, 5], Tlist()))
// > [ true, [] ]
console.log(Check({ property: "value" }, Tlist()))
// > [ false, [ '*: Expected (*) to be of type `array`' ] ]
console.log(Check(["one", "two", "three"], Tlist(Tstring())))
// > [ true, [] ]
console.log(Check([1, "two", 3], Tlist(Tnumber())))
// > [ false, [ '* > [1]: Expected [1] to be of pattern defined' ] ]
console.log(Check([1, "two", []], Tlist(Tstring(), Tnumber(), Tlist())))
// > [ true, [] ]
// And yes we also can verify Tlist() within Tlist()
console.log(Check([1, "two", null], Tlist(Tstring(), Tnumber())))
// > [ false, [ '* > [2]: Expected [2] to be of pattern defined' ] ]
const usernames = ["jack", "_jack", "-jack"]
console.log(Check(usernames, Tlist(Tstring(/^[a-zA-Z]/))))
// > [
// > false,
// > [
// > '* > [1]: Expected [1] to be of pattern defined',
// > '* > [2]: Expected [2] to be of pattern defined'
// > ]
// > ]
// Not every username matched /^[a-zA-Z]/
const codes = [34, 76, 92]
console.log(Check(codes, Tlist(Tnumber(34, 76, 92))))
// > [ true, [] ]
// Every code matched items in [34, 76, 92]
This way, we can make checking of list types much more detailed
Tobject()Last but not least, in fact most importantly, we can use Tobject() to validate objects. Tobject only allows 1 optional parameter which maps out what the inner properties will look like
import { Check, Tobject } from "validate-all-types"
console.log(Check({ property: "value" }, Tobject()))
// > [ true, [] ]
// Since { property: "value" } is an object, Check() returned true
console.log(Check(
{ property: "value" },
Tobject({ property: Tstring() }
)))
// > [ true, [] ]
// We set the Tobject's params to an object with a property "property" and a value "value"
// Since "value" matches Tstring(), Check() returned true
console.log(Check(
{
property: "value"
},
Tobject({
prop: Tstring()
})
))
// > [
// > false,
// > [
// > '*: Expected (*) to contain property (prop)',
// > '* > property: No type definitions for (property)'
// > ]
// > ]
// Since there is no property for the type validation "prop", we got an error
// Since there is no type validation for the property "property", we got an error
console.log(Check(
{
property: "value",
layer: {
deepProperty: ["", 0, null, undefined, false]
}
},
Tobject({
property: Tstring(),
layer: Tobject({
deepProperty: Tlist(Tstring(), Tnumber(0), Tnull(), Tundefined(), Tboolean(false))
})
})
))
// > [ true, [] ]
// We can even nest Tobject() in Tobject()
We can combine what we've learnt and move on to the next Chapter. We can use logical operators to string together more complex pattern types.
Tor()If you want either of a few patterns to match, use the Tor() operator. This function takes multiple parameters:
| Type | Description |
|---|---|
| ...ITpattern[] | A list of patterns to test on the input |
import { Check, Tor, Tstring, Tnumber, Tboolean } from "validate-all-types"
console.log(Check("string", Tor()))
// > [
// > false,
// > [
// > '*: Expected developer to provide at least 1 pattern for the OR operation'
// > ]
// > ]
console.log(Check(
"string",
Tor(Tstring(), Tnumber())
))
// > [ true, [] ]
console.log(Check(
"string",
Tor(Tboolean(), Tnumber())
))
// > [
// > false,
// > [ '*: Expected (*) to match at least one of the given patterns' ]
// > ]
Tand()If you need an object to be of multiple patterns at once, (WHY would anyone need this???) you can use the Tand() operator. This operator works the same way as the Tor() operator and takes a few parameters:
| Type | Description |
|---|---|
| ...ITpattern[] | A list of patterns to test on the input |
import { Check, Tand, Tstring, Tboolean } from "validate-all-types"
console.log(Check("string", Tand()))
// > [
// > false,
// > [
// > '*: Expected developer to provide at least 1 pattern for the AND operation'
// > ]
// > ]
console.log(Check(
"string",
Tand(
Tstring(),
Tstring("string"),
Tstring(/^string$/)
)
))
// > [ true, [] ]
console.log(Check(
"string",
Tand(Tstring("string"), Tboolean())
))
// > [ false, [ '*: Expected (*) to be of type `boolean`' ] ]
Developer side-note: You probably won't ever need to use this. This module was just included just in case someone needed it. Almost all the time, types don't cross over. You can't have a variable of type "string" AND "number" at once!!!
Tnot()If you want the result of a pattern to be flipped, you can use the Tnot() operator which takes only 1 parameter:
| Type | Description |
|---|---|
| ITpattern | Pattern which boolean should be reversed |
This is applicable in cases where you don't want a variable to be of a certain type
import { Check, Tnot, Tstring, Tnumber } from "validate-all-types"
console.log(Check("string", Tnot(Tnumber())))
// > [ true, [] ]
console.log(Check("string", Tnot(Tstring())))
// > [ false, [ '*: Expected (*) to not match the given pattern' ] ]
ValidateRequest with ExpressYou can also import a middleware to be used with express. This way, you can verify the types of the req.body or req.params before invalid types mess your server up
import { ValidateRequest, Tobject, Tstring } from "validate-all-types"
// ----snip----
app.post("/body",
ValidateRequest("body", Tobject({ usnm: Tstring(), pswd: Tstring() })),
(req, res) => {
const { usnm, pswd } = req.body as { usnm: string, pswd: string }
console.log(`Username: ${usnm}`, `Password: ${pswd}`)
res.end()
}
)
// ----snip----
The ValidateRequest takes in 2 parameters:
| Number | Type | Description |
|---|---|---|
| 1 | "body" | "params" | Can either verify the req.body or req.params object |
| 2 | ITpattern | Pattern to compare the object with |
Because of the middleware, in Typescript you can now safely use type assertions. Also, now for both Typescript and Javascript, you can safely use the variables like they are the defined types and not have to worry about invalid types crashing your server!
FAQs
Validator for all interfaces
The npm package validate-all-types receives a total of 0 weekly downloads. As such, validate-all-types popularity was classified as not popular.
We found that validate-all-types demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Security News
New DoS and source code exposure bugs in React Server Components and Next.js: what’s affected and how to update safely.

Security News
Socket CEO Feross Aboukhadijeh joins Software Engineering Daily to discuss modern software supply chain attacks and rising AI-driven security risks.

Security News
GitHub has revoked npm classic tokens for publishing; maintainers must migrate, but OpenJS warns OIDC trusted publishing still has risky gaps for critical projects.