schema-dsl Quick Start
Start here if you are new to schema-dsl. After this page, continue with DSL Syntax for authoring rules and Validation Guide for real validation flows.
Installation
Node.js requirement:
>=18.0.0The current TypeScript rewrite uses
Node.js >=18.0.0as the only runtime baseline and no longer promises compatibility with older Node versions.This documentation follows the current
mainbranch source. If npm latest is older than this commit, install from the matching tag/commit or use the next published npm release before relying on theschema-dsl/pure,schema-dsl/runtime,schema-dsl/transform, orschema-dsl/esbuildentry points.
5-minute Quick Start
1. Hello World in 30 seconds
Explanation:
'string:1-50!'means a required string with length 1 to 50.'email!'means a required email field.!marks a field as required.
2. DSL syntax cheat sheet in 1 minute
Syntax rules:
type:max-> maximum value or length, shorthandtype:min-max-> rangetype:min--> minimum onlytype:-max-> maximum only
3. Chainable fields in 2 minutes
The recommended authoring entry is schema-dsl/pure with the s namespace. Keep simple fields as DSL strings, wrap a DSL seed with s('...') when you need chain methods such as .label(), .messages(), .pattern() or .custom(), and use s.xxx() factories when you want the strongest TypeScript method discovery.
Available methods:
.pattern(regex)- regular expression validation.label(text)- field label.messages(obj)- custom messages.description(text)- description.custom(fn)- custom validator
4. Complete example in 2 minutes
Best Practices
1. Use plain DSL for simple fields
2. Use chain APIs for complex fields
3. The 80/20 rule
Use plain DSL strings for simple fields. Use s('...') when a field needs labels, messages, regexes or custom validators. Use s.xxx() factories when you want the most complete TypeScript method discovery.
Common Scenarios
Form validation
Custom validation
.custom()supports synchronous functions. If it returns aPromise, usevalidateAsync(). Synchronousvalidate()returns an explicit error when it sees a Promise-returning custom validator.
Nested objects
Object arrays
Next Steps
Learn more
Example code
Other topic examples are linked from the bottom of their own documents and use stable GitHub example links.
Advanced features
Entry choices
Use schema-dsl/pure for ordinary application code. It gives you the same schema authoring API without installing global String methods.
Use schema-dsl/runtime when a framework, plugin host or multi-tenant app needs an isolated runtime instance:
Use String Extensions or the compile-time transform only when you intentionally want direct string-chain authoring such as 'email!'.label('Email'). See String Extensions and Runtime Isolation for the boundary.
For design background and benchmark data, continue with Design Philosophy and Performance Guide.
FAQ
Q: What is the difference between String extensions and plain DSL?
A:
- Plain DSL: best for simple fields, concise syntax.
s('...')chain API: best for complex fields without relying on global prototype changes.s.xxx()factories: best when you want the strongest TypeScript method discovery.- String extensions: available when you intentionally enable direct string-chain authoring.
Q: How do I explicitly enable String extensions?
A:
For cleanup in tests or legacy compatibility details, see String Extensions.
Q: Does schema-dsl support TypeScript?
A: Yes. schema-dsl ships complete TypeScript type definitions.
Congratulations
You now know the core schema-dsl workflow.
Key takeaways:
- DSL syntax is concise and readable.
schema-dsl/pure+sis the recommended default entry for application code.s('...')gives explicit DSL seeds plus builder hints.s.xxx()factories provide the strongest method discovery.
Start using it: npm install schema-dsl
Corresponding Example File
Example entry: quick-start.ts
Description: Covers the Hello World flow, the schema-dsl/pure + s authoring path, a user registration example, and the basic validate() plus Validator.compile() reuse path from the quick start. It can be run directly as a reference.