Compatibility

This page records compatibility policy for developers using dblurt.

Runtime support

The package metadata is canonical for runtime requirements:

• engines.node defines the supported Node.js floor;
• types / typings define TypeScript declaration entrypoints;
• browser defines browser bundle substitutions;
• browserslist describes browser capability expectations.

Do not assume support for a runtime that is not represented by package metadata or validation.

API compatibility

dblurt is pre-1.0, but public API compatibility still matters.

Current documentation policy:

• additive APIs should be introduced through concept/task docs when they change how developers think about the SDK;
• exact method and type details belong in the API reference;
• legacy supported APIs should remain visible;
• deprecated APIs should point to replacements;
• positional Nexus overloads remain compatibility surfaces unless a future release intentionally changes that policy;
• examples should prefer new and corrected forms.

Generated artifacts

Some repository directories are build outputs and should not be edited by hand. This is mostly a maintainer concern, but it matters if you are contributing documentation or API changes.

Artifact	Meaning
docs/	API reference output
lib/	compiled library output
dist/	browser bundle output
site/.vitepress/dist/	documentation site output

Related references:

• API reference
• Deprecations
• Runtime and browser