1.0 Roadmap

[sluukkonen]

• Add missing codecs for built-in types
  • null
  • undefined
  • bigint
  • date (accepts valid Date objects)
  • integer
  • set(members)
  • map(keys, values)
  • unknown
• Add missing basic combinators
  • tuple([...codecs])
  • nullable(codec)
  • brand(codec, brand)
  • pattern(codec, regexp)
  • refinement(codec, predicate, makeError)
  • taggedUnion(tag, ...codecs)
  • intersection(...codecs)
• Add codecs for parsing some built-in data types from a JSON-serializable format (how to name these?)
  • bigintFromString
  • setFromArray (serialized to an array)
  • dateFromString (currently named as date)
  • mapFromEntries (serialized to an array of key-value tuples)
• Add missing object combinators, such as
  • A version of object that doesn't strip extra keys
  • partial(props)
• Built-in refinements, such as
  • email
  • uuid
• Think about how to support Temporal API
• Add support for recursive types (e.g. lazy)
• Add some structured way to restrict input values more carefully (minimum length, maximum length, value greater than, value less than, regex pattern etc.). Should work with built-in codecs like string, array, number, bigint etc. The additional restrictions should be stored in the metadata for introspection.
• With the above machinery, add some convenience codecs like nonEmptyArray or nonEmptyString, positiveInteger etc.
• Do a polish pass on error types
  • Decide on the set of built-in error types
  • Add human readable messages to errors ("Expected value to be a string" etc.)
  • Add actual/expected values to error types
  • Decide if the path property should be a string or an array
  • Try out @milankinen's idea for getting rid of the separate validate method
• Fix tree shaking by adding necessary pure annotations
• Add more comprehensive benchmarks & tune performance accordingly
• Add documentation
  • Add general documentation to README
  • Add comprehensive TSDoc comments to the public API
  • Generate API docs from the TSDoc comments
• Try to write something like an JSON schema generator to try out the introspection capabilities

[japiirainen]

Regarding missing codecs for built-in types , is integer a built in JS type? I thought the only number types are number and bigint. I guess these could belong to the refinement category along email, uuid, url, etc...

This category could perhaps also include even more number types such as natural and float.

Thoughts?

[sluukkonen]

Regarding missing codecs for built-in types , is integer a built in JS type? I thought the only number types are number and bigint. I guess these could belong to the refinement category along email, uuid, url, etc...

So far this document has been mostly been just a lightweight TODO list for me, so all the categorizations are a bit fast and loose at the moment. You're of course correct that integer could be in the refinement category.

This category could perhaps also include even more number types such as natural and float.

Thoughts?

With naturals you have the problem of not knowing whether to start with 0 or 1, but I think something like could be useful, yes. Maybe call them positiveInteger and nonNegativeInteger or something.

What would a float codec check? How would it differ from the existing number codec?