! suffix on string types does not enforce non-null / required validation

[iDevo-ll]

When using the ! suffix on string types (e.g. "string!") in Fortify Schema, the validation for non-null / required fields is not always enforced as expected. In particular:

Interface({ x: "string!" }) does not produce an error when x is omitted or null.

In some combinations, e.g. Interface({ x: "string(0.5)!" }), the ! suffix seems to be ignored or overridden — even though string(0.5) is invalid, the “required” constraint is dropped in certain cases.

Thus, ! should guarantee presence (non-nullable), but in practice it’s not consistently respected when combined with other constraints.

---

Expected Behavior

A field declared as "string!" should be required — missing or null/undefined values should result in a validation error.

For "string(0.5)!" (or any invalid constraint + !), the required-ness of ! should still be respected first, even if the type constraints are invalid or nonsensical.

---

Reproduction Steps / Minimal Example

import { Interface } from "fortify-schema";

const Schema1 = Interface({
x: "string!"
});

const result1 = Schema1.safeParse({});
// ✅ Expected: result1.success === false, with an error complaining “x is required”
// ❌ Observed: result1.success === true (no error)

const Schema2 = Interface({
x: "string(0.5)!"
});

const result2 = Schema2.safeParse({ x: "foo" });
// ✅ Expected: an error, because “string(0.5)” is invalid (and/or because ! should force validation)
// ❌ Observed: the ! constraint is seemingly ignored in some cases

I can share a small reproducible npm sandbox if needed.

---

Environment / Context

Version of fortify-schema (exact version)

Node.js version

TypeScript or plain JavaScript environment

Any compiler or runtime flags

If possible, a reference to the documentation or official description of the ! suffix in Fortify Schema, to show expected semantics

---

Possible Causes / Suggestions for Investigation

The order of parsing or applying modifiers may be wrong: ! could be applied before or after other constraints, causing it to be overridden.

In combined constraint expressions, ! might be ignored or lost when the parser sees an invalid constraint like (0.5).

Lack of test coverage for combinations of ! + invalid constraint types.

The internal validation logic may skip “required” checks if type constraints are malformed.