fix(deps): update dependency superstruct to ^0.16.0
This PR contains the following updates:
| Package | Change | Age | Adoption | Passing | Confidence |
|---|---|---|---|---|---|
| superstruct | ^0.8.2 -> ^0.16.0 |
Release Notes
ianstormtaylor/superstruct (superstruct)
v0.16.7
v0.16.6
v0.16.5
v0.16.4
v0.16.3
v0.16.2
v0.16.1
v0.16.0
BREAKING
Refinement functions are now called with valid, but potentially unrefined values. Previously the functions passed in to refine would always be called with sub-elements (eg. when using objects or arrays) that were completely valid and refined. However, this prevented collecting all the refinement errors from subelements in a validation in one go, which is common when validating forms. Note: this should not have any affect on almost all use cases, so you're safe to upgrade.
v0.15.5
v0.15.4
v0.15.3
v0.15.2
v0.15.1
v0.15.0
FIXED
Unions can now be coerced. Previously unions created a barrier in coercion such that structs nested inside unions would not have their coercion logic triggered, but this has been fixed.
Assigning preserves type structs. Previously using the assign helper would implicitly convert type structs into object structs which wasn't expected and confusing, but this has been fixed.
v0.14.2
v0.14.1
v0.14.0
BREAKING
The mask helper now works for nested objects. Previously it would only mask the properties at the top-level of a struct, however now it acts deeply. You can use it to define object structs once, but use them either strictly or loosely.
The masked coercion has been removed. This previously allowed you to mix in masking to a specific struct, but the mask helper is a more robust way to do this, and it doesn't force you to maintain two separate structs.
v0.13.3
v0.13.2
v0.13.1
v0.13.0
NEW
Structs can now define an entries iterator for nested values. Previously iterating through nested values was defined in a one-off manner inside certain structs, but this led to non-uniform support. Now, any struct can define an entries iterator that will cause nested values to be automatically coerced and validated.
Coercion receives context objects and supports nested values. Previously context objects were only passed to the validations and refinements. But now the same context is passed to coercions too so you can implement more complex logic. And coercions are automatically applied to nested values thanks to the addition of entries.
Iteration logic has gotten simpler, and more performant. The addition of the entries logic has enabled us to only ever iterate through a tree of values one time for coercion and validation, instead of once each. This should speed up most standard use cases.
BREAKING
The ctx.fail() function has been removed. Previously you'd use it to return more information about a failure inside a struct. Now you can simply return a partial failure object.
The ctx.check() function has been removed. Previously you'd use it to validate nested objects in more complex struct shapes. Now you can use the new entries property for this instead.
The context.struct and context.value properties have been removed. These properties were previously available, but unnecessary since anywhere you have the context object you will also know the value and the specific struct that is being validated. Keeping them around required extra unnecessary plumbing in the library that made composing structs much more difficult so they were removed.
v0.12.2
v0.12.1
v0.12.0
NEW
New Describe utility type. This new utility lets you define a struct from an existing TypeScript type and ensure that the struct's validation matches it, otherwise TypeScript's compiler will error. For example:
type User = {
id: number
name: string
}
const User: Describe<User> = object({
id: string(), // This mistake will fail to pass type checking!
name: string(),
})
BREAKING
The coerce helper has changed to be more type-safe! Previously coerce functions were called with value: unknown because they ran before all validation. However, now they take a new second argument that is another struct to narrow the cases where coercions occurs. This means the value for coercion will now be type-safe.
// Previously
const MyNumber = coerce(number(), (value) => {
return typeof value === 'string' ? parseFloat(value) : value
})
// Now
const MyNumber = coerce(number(), string(), (value) => {
return parseFloat(value)
})
v0.11.1
v0.11.0
NEW
New assign, pick, and omit object utilities. These utilities make composing object structs together possible, which should make re-using structs in your codebase easier.
// Combine two structs with `assign`:
const a = object({ id: number() })
const b = object({ name: string() })
const c = assign([a, b])
// Pick out specific properties with `pick`:
const a2 = pick(c, ['id'])
// Omit specific properties with `omit`:
const a3 = omit(c, ['name'])
New unknown struct. This is the same as the existing any struct, but it will ensure that in TypeScript the value is of the more restrictive unknown type so it encourages better type safety.
const Shape = type({
id: number(),
name: string(),
other: unknown(),
})
New integer, regexp, and func structs. These are just simple additions for common use cases of ensuring a value is an integer, a regular expression object (not a string!), or a function.
const Shape = type({
id: integer(),
matches: regexp(),
send: func(),
})
New max/min refinements. For refining number (or integer) or date structs to ensure they are greater than or less than a specific threshold. The third argument can indicate whether to make the threshold exclusive (instead of the default inclusive).
const Index = min(number(), 0)
const PastOrPresent = max(date(), new Date())
const Past = max(date(), new Date(), { exclusive: true })
Even more information on errors. Errors now expose the error.refinement property when the failure originated in a refinement validation. And they also now have an error.key property which is the key for the failure in the case of complex values like arrays/objects. (Previously the key was retrievable by checking error.path, but this will make the 90% case easier.)
BREAKING
The coerce helper has been renamed to create. This will hopefully make it more clear that it's fully coercing and validating a value against a struct, throwing errors if the value was invalid. This has caused confusion for people who though it would just coerce the value and return the unvalidated-but-coerced version.
// Previously
const user = coerce(data, User)
// Now
const user = create(data, User)
The struct, refinement and coercion factories have been renamed. This renaming is purely for keeping things slightly cleaner and easier to understand. The new names are define, refine, and coerce. Separating them slightly from the noun-based names used for the types themselves.
// Previously
const Email = struct('email', isEmail)
const Positive = refinement('positive', number(), n => n > 0)
const Trimmed = coercion(string(), s => s.trim()
// Now
const Email = define('email', isEmail)
const Positive = refine(number(), 'positive', n => n > 0)
const Trimmed = coerce(string(), s => s.trim())
Note that the order of refine arguments has changed to be slightly more natural, and encourage scoped refinement names.
The length refinement has been renamed to size. This is to match with the expansion of it's abilities from purely strings and arrays to also now include numbers, maps, and sets. In addition you can also omit the max argument to specify an exact size:
// Previously
const Name = length(string(), 1, 100)
const MyArray = length(array(string()), 3, 3)
// Now
const Name = size(string(), 1, 100)
const MyArray = size(array(string()), 3)
const Id = size(integer(), 1, Infinity)
const MySet = size(set(), 1, 9)
The StructType inferring helper has been renamed to Infer. This just makes it slightly easier to read what's going on when you're inferring a type.
// Previously
type User = StructType<typeof User>
// Now
type User = Infer<typeof User>
The error.type property has been standardized. Previously it was a human-readable description that sort of incorporated the schema. Now it is simple the plain lowercase name of the struct in question, making it something you can use programmatically when formatting errors.
// Previously
'Array<string>'
'[string,number]'
'Map<string,number>'
// Now
'array'
'tuple'
'map'
v0.10.13
v0.10.12
v0.10.11
v0.10.10
v0.10.9
v0.10.8
v0.10.7
v0.10.6
v0.10.4
v0.10.3
v0.10.2
v0.10.1
v0.10.0
The 0.10 version is a complete overhaul with the goal of making Superstruct much simpler and easier to understand, and with complete support for runtime type signatures TypeScript.
This makes it much more powerful, however the core architecture has had to change to make it happen. It will still look very similar, but migrating between the versions will be more work than usual. There's no requirement to upgrade, although if you're using Superstruct in concert with TypeScript you will have a much better experience.
BREAKING
All types are created from factories. Previously depending on whether the type was a complex type or a scalar type they'd be defined different. Complex types used factories, whereas scalars used strings. Now all types are exposed as factories.
For example, previously:
import { struct } from 'superstruct'
const User = struct.object({
name: 'string',
age: 'number',
})
Now becomes:
import { object, string, number } from 'superstruct'
const User = object({
name: string(),
age: number(),
})
Custom scalars are no longer pre-defined as strings. Previously, you would define all of your "custom" types in a single place in your codebase and then refer to them in structs later on with a string value. This worked, but added a layer of unnecessary indirection, and made it impossible to accomodate runtime type signatures.
In the new version, custom types are defined extremely similarly to non-custom types. And this has the added benefit that you can easily trace the custom type definitions by just following import statements.
Here's how it used to work:
import { superstruct } from 'superstruct'
import isEmail from 'is-email'
const struct = superstruct({
types: {
email: isEmail,
},
})
const Email = struct('email')
And here's what it would look like now:
import { struct } from 'superstruct'
import isEmail from 'is-email'
const Email = struct('email', isEmail)
Validation logic has been moved to helper functions. Previously the assert and is helpers lived on the struct objects themselves. Now, these functions have been extracted into separate helpers. This was unfortunately necessary to work around limitations in TypeScript's asserts keyword.
For example, before:
User.assert(data)
Now would be:
import { assert } from 'superstruct'
assert(data, User)
Coercion is now separate from validation. Previously there was native logic for handling default values for structs when validating them. This has been abstracted into the ability to define any custom coercion logic for structs, and it has been separate from validation to make it very clear when data can change and when it cannot.
For example, previously:
const output = User.assert(input)
Would now be:
const input = coerce(input, User)
The coerce step is the only time that data will be transformed at all by coercion logic, and the assert step no longer needs to return any values. This makes it easy to do things like:
if (is(input, User)) {
// ...
}
Validation context is now a dictionary of properties. Previously when performing complex validation logic that was dependent on other properties on the root object, you could use the second branch argument to the validation function. This argument has been changed to be a context dictionary with more information. The same branch argument can now be accessed as context.branch, along with the new information.
Unknown properties of objects now have a 'never' type. Previously unknown properties would throw errors with type === null, however the newly introduced 'never' type is now used instead.
Defaults are now defined with a separate coercion helper. Previously all structs took a second argument that defined the default value to use if an undefined value was present. This has been pulled out into a separate helper now to clearly distinguish coercion logic.
For example, previously you'd do:
const Article = struct.object(
{
title: 'string',
},
{
title: 'Untitled',
}
)
Whereas now you'd do:
const Article = defaulted(
object({
title: string(),
}),
{
title: 'Untitled',
}
)
Optional arguments are now defined with a seperate factory. Similarly to defaults, there is a new optional factory for defined values that can also be undefined.
Previously you'd do:
const Flag = struct('string?')
Now you'd do:
const Flag = optional(string())
Several structs have been renamed. This was necessary because structs are now exposed directly as variables, which runs afoul of reserved words. So the following renames have been applied:
-
interface->type -
enum->enums -
function->func
v0.8.4
v0.8.3
Configuration
📅 Schedule: Branch creation - "every weekend" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
â™» Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
- [ ] If you want to rebase/retry this PR, check this box
This PR was generated by Mend Renovate. View the repository job log.