superstruct - npm Package Compare versions

Comparing version 0.0.1 to 0.0.2

dist/superstruct.js

dist/superstruct.min.js

package.json

		{
		"name": "superstruct",
		"description": "A simple, expressive way to validate data in Javascript.",
		"version": "0.0.1",
		"version": "0.0.2",
		"license": "MIT",
		@@ -9,3 +9,6 @@ "repository": "git://github.com/ianstormtaylor/superstruct.git",
		"scripts": {
		"build": "babel ./src --out-dir ./lib",
		"build": "yarn run build:lib && yarn run build:max && yarn run build:min",
		"build:lib": "babel ./src --out-dir ./lib",
		"build:max": "mkdir -p ./dist && NODE_ENV=production browserify ./src/index.js --transform babelify --transform envify --standalone Superstruct > ./dist/superstruct.js",
		"build:min": "mkdir -p ./dist && NODE_ENV=production browserify ./src/index.js --transform babelify --transform envify --transform uglifyify --standalone Superstruct \| uglifyjs > ./dist/superstruct.min.js",
		"clean": "rm -rf ./lib ./node_modules",
		@@ -15,4 +18,5 @@ "lint": "eslint src/* test/*",
		"release": "np",
		"test": "yarn run build && mocha --compilers js:babel-core/register ./test/index.js",
		"watch": "babel ./lib --out-dir ./lib --watch"
		"test": "yarn run build:lib && mocha --compilers js:babel-core/register ./test/index.js",
		"watch": "yarn run watch:lib",
		"watch:lib": "babel ./lib --out-dir ./lib --watch"
		},
		@@ -29,2 +33,5 @@ "dependencies": {
		"babel-preset-stage-0": "^6.5.0",
		"babelify": "^7.3.0",
		"browserify": "^13.0.1",
		"envify": "^3.4.1",
		"eslint": "^3.8.1",
		@@ -34,3 +41,6 @@ "eslint-plugin-import": "^2.0.1",
		"mocha": "^3.2.0",
		"np": "^2.13.1"
		"np": "^2.13.1",
		"uglify-js": "^2.7.0",
		"uglifyify": "^3.0.2",
		"watchify": "^3.7.0"
		},
		@@ -37,0 +47,0 @@ "keywords": [

Readme.md

		@@ -116,14 +116,16 @@

		There are lots of existing validation libraries. Some of them, like [Joi](), are fairly popular. But most of them exhibit one or many issues...
		There are lots of existing validation libraries. Some of them, like [Joi](), [`express-validator`](https://github.com/ctavan/express-validator), [`validator.js`](https://github.com/chriso/validator.js) or [`ajv`](https://github.com/epoberezkin/ajv) are decently popular. But all of them exhibit many issues that lead to hard to maintain codebases...

		- Not throwing the errors. Many validators simply return `true/false` or return details about the error. This was nice back in the days of callbacks, where throwing was discouraged, but in modern Javascript using `throw` leads to much simpler code.
		- They don't throw errors. Many validators simply return `true/false` or return string error messages. This was helpful in the days of callbacks, when using `throw` was discouraged, but in modern Javascript using `throw` leads to much simpler and terser code.

		- Not making it easy to define custom types. Lots of the validators ship with built-in types like emails, URLs, UUIDs, etc. But they often don't take into account things like maximum lengths, or But once you need to define your own custom types—which any reasonably sized use case will require—the APIs are complex, and poorly supported.
		- They don't expose useful error information. For the validators that do `throw`, they often throw over-simplified, message-only errors without any extra details about the reason the error occurred. This makes it very difficult to customize the errors to make them helpful for end users.

		- Not having single sources of truth. Many of the existing APIs encourage re-defining data types like names, emails, or over and over, with the source of truth being spread out across many files. This leads to
		- They aren't designed around custom types. Many validators ship with built-in types like emails, URLs, UUIDs, etc. with no easy way to know how they're implemented. And when defining your own custom types—which any reasonably sized codebase needs to do—the APIs are needlessly complex and hard to re-use.

		- Not treating errors as part of the API. For the validators that do throw errors, they often throw simple message-only errors without any extra information. This makes it hard to customize the error message to make them helpful for users.
		- They don't encourage single sources of truth. Many existing APIs encourage re-defining custom data type requirements like maximum lengths, custom types, error messages, etc. over and over, with the source of truth being spread out across many files, which makes consistentcy difficult to maintain.

		- Not compiling schemas on creation. Some validators allow you to define schemas as plain Javascript objects, which seems nice. But then they delegate the more complex parsing and compiling logic to validation time, instead of doing the work up front.
		- They don't compile schemas for performance. Some validators allow you to define schemas as plain Javascript objects, which seems nice at first. But it also means that they delegate the complex parsing of the schema logic to validation time, instead of doing the work up front for performance.

		- They are tightly coupled to other concerns. Many validators are implemented as plugins for Express or other HTTP frameworks, which is completely unnecessary and confusing to reason about. And since you can only use them with a web server you end up with even more fragmentation in your codebase.

		Of course, not every validation library suffers from all of these issues, but most of them exhibit at least one. If you've run into this problem before, you might like Superstruct.
		@@ -138,15 +140,15 @@

		1. Customizable types. Superstruct's power is in making it easy to define an entire set of custom data types that are specific to your application, so that you have full control over exactly what you're checking for.
		1. Customizable types. Superstruct's power is in making it easy to define an entire set of custom data types that are specific to your application, and defined in a _single_ place, so you have full control over your requirements.

		2. Unopinionated defaults. Superscript only ships with the native Javascript types by default, that you never have to fight to override decisions made by "core" that differ from your application's needs.
		2. Unopinionated defaults. Superscript ships with native Javascript types, and everything else is customizable, so you never have to fight to override decisions made by "core" that differ from your application's needs.

		4. Composable interfaces. Superstruct interfaces are composable, so you can break down commonly-repeated pieces into smaller components, and compose them to make up the more complex.
		4. Composable interfaces. Superstruct interfaces are composable, so you can break down commonly-repeated pieces of data into components, and compose them to build up the more complex objects.

		5. Terse schemas. The schemas in Superstruct are designed to be extremely terse. This makes them very easy to read and write, so that you're encouraged to have full data validation coverage.
		5. Terse schemas. The schemas in Superstruct are designed to be extremely terse. This makes them very easy to read and write, encouraging you to have full data validation coverage.

		3. Familiar API. The Superstruct API was heavily inspired by Typescript, Flow and GraphQL. If you're familiar with any of those then its schema definition API will feel very natural to use, so you can get started quickly.
		7. Compiled validators. Superstruct does the work of compiling its schemas up front, so that it doesn't have to spend lots of time performing expensive tasks for every call to the validation functions in your hot code paths.

		6. Useful errors. The errors that Superstruct throws contain all the information you need to convert them into your own application-specific errors easy, which means more helpful errors for your end users!

		7. Compiled validators. Superstruct does the work of compiling its schemas up front, so that it doesn't have to spend lots of time performing expensive tasks for every call to the validation functions in your hot code paths.
		3. Familiar API. The Superstruct API was heavily inspired by [Typescript](https://www.typescriptlang.org/docs/handbook/basic-types.html), [Flow](https://flow.org/en/docs/types/) and [GraphQL](http://graphql.org/learn/schema/). If you're familiar with any of those, then its schema definition API will feel very natural to use, so you can get started quickly.

		@@ -153,0 +155,0 @@

yarn.lock

Sorry, the diff of this file is not supported yet

		@@ -116,14 +116,16 @@

		There are lots of existing validation libraries. Some of them, like [Joi](), are fairly popular. But most of them exhibit one or many issues...
		There are lots of existing validation libraries. Some of them, like [Joi](), [`express-validator`](https://github.com/ctavan/express-validator), [`validator.js`](https://github.com/chriso/validator.js) or [`ajv`](https://github.com/epoberezkin/ajv) are decently popular. But all of them exhibit many issues that lead to hard to maintain codebases...

		- Not throwing the errors. Many validators simply return `true/false` or return details about the error. This was nice back in the days of callbacks, where throwing was discouraged, but in modern Javascript using `throw` leads to much simpler code.
		- They don't throw errors. Many validators simply return `true/false` or return string error messages. This was helpful in the days of callbacks, when using `throw` was discouraged, but in modern Javascript using `throw` leads to much simpler and terser code.

		- Not making it easy to define custom types. Lots of the validators ship with built-in types like emails, URLs, UUIDs, etc. But they often don't take into account things like maximum lengths, or But once you need to define your own custom types—which any reasonably sized use case will require—the APIs are complex, and poorly supported.
		- They don't expose useful error information. For the validators that do `throw`, they often throw over-simplified, message-only errors without any extra details about the reason the error occurred. This makes it very difficult to customize the errors to make them helpful for end users.

		- Not having single sources of truth. Many of the existing APIs encourage re-defining data types like names, emails, or over and over, with the source of truth being spread out across many files. This leads to
		- They aren't designed around custom types. Many validators ship with built-in types like emails, URLs, UUIDs, etc. with no easy way to know how they're implemented. And when defining your own custom types—which any reasonably sized codebase needs to do—the APIs are needlessly complex and hard to re-use.

		- Not treating errors as part of the API. For the validators that do throw errors, they often throw simple message-only errors without any extra information. This makes it hard to customize the error message to make them helpful for users.
		- They don't encourage single sources of truth. Many existing APIs encourage re-defining custom data type requirements like maximum lengths, custom types, error messages, etc. over and over, with the source of truth being spread out across many files, which makes consistentcy difficult to maintain.

		- Not compiling schemas on creation. Some validators allow you to define schemas as plain Javascript objects, which seems nice. But then they delegate the more complex parsing and compiling logic to validation time, instead of doing the work up front.
		- They don't compile schemas for performance. Some validators allow you to define schemas as plain Javascript objects, which seems nice at first. But it also means that they delegate the complex parsing of the schema logic to validation time, instead of doing the work up front for performance.

		- They are tightly coupled to other concerns. Many validators are implemented as plugins for Express or other HTTP frameworks, which is completely unnecessary and confusing to reason about. And since you can only use them with a web server you end up with even more fragmentation in your codebase.

		Of course, not every validation library suffers from all of these issues, but most of them exhibit at least one. If you've run into this problem before, you might like Superstruct.
		@@ -138,15 +140,15 @@

		1. Customizable types. Superstruct's power is in making it easy to define an entire set of custom data types that are specific to your application, so that you have full control over exactly what you're checking for.
		1. Customizable types. Superstruct's power is in making it easy to define an entire set of custom data types that are specific to your application, and defined in a _single_ place, so you have full control over your requirements.

		2. Unopinionated defaults. Superscript only ships with the native Javascript types by default, that you never have to fight to override decisions made by "core" that differ from your application's needs.
		2. Unopinionated defaults. Superscript ships with native Javascript types, and everything else is customizable, so you never have to fight to override decisions made by "core" that differ from your application's needs.

		4. Composable interfaces. Superstruct interfaces are composable, so you can break down commonly-repeated pieces into smaller components, and compose them to make up the more complex.
		4. Composable interfaces. Superstruct interfaces are composable, so you can break down commonly-repeated pieces of data into components, and compose them to build up the more complex objects.

		5. Terse schemas. The schemas in Superstruct are designed to be extremely terse. This makes them very easy to read and write, so that you're encouraged to have full data validation coverage.
		5. Terse schemas. The schemas in Superstruct are designed to be extremely terse. This makes them very easy to read and write, encouraging you to have full data validation coverage.

		3. Familiar API. The Superstruct API was heavily inspired by Typescript, Flow and GraphQL. If you're familiar with any of those then its schema definition API will feel very natural to use, so you can get started quickly.
		7. Compiled validators. Superstruct does the work of compiling its schemas up front, so that it doesn't have to spend lots of time performing expensive tasks for every call to the validation functions in your hot code paths.

		6. Useful errors. The errors that Superstruct throws contain all the information you need to convert them into your own application-specific errors easy, which means more helpful errors for your end users!

		7. Compiled validators. Superstruct does the work of compiling its schemas up front, so that it doesn't have to spend lots of time performing expensive tasks for every call to the validation functions in your hot code paths.
		3. Familiar API. The Superstruct API was heavily inspired by [Typescript](https://www.typescriptlang.org/docs/handbook/basic-types.html), [Flow](https://flow.org/en/docs/types/) and [GraphQL](http://graphql.org/learn/schema/). If you're familiar with any of those, then its schema definition API will feel very natural to use, so you can get started quickly.

		@@ -153,0 +155,0 @@

superstruct - npm Package Compare versions

New alerts

Fixed alerts

Improved metrics

Worsened metrics