Add depth-limited type checking for discriminated unions

[Copilot]

Discriminated unions often only need shallow validation of a discriminator field, but typia.is<T>() validates the entire object tree. This generates excessive code and wastes runtime for what should be a simple check.

Changes

New APIs

• typia.isShallow<T>(input, maxDepth?) - Type guard with depth limit (default: 2)
• typia.createIsShallow<T>(maxDepth?) - Factory for reusable shallow validators

Implementation

• Depth tracking in IExplore - Added depth and maxDepth fields to track validation depth
• Early return in CheckerProgrammer.decode() - Returns true when depth >= maxDepth, skipping deep validation
• incrementDepth() helper - Increments depth when entering nested structures (objects, arrays, tuples, maps, sets)
• Transformers - Extract maxDepth from runtime arguments, pass to programmer config

Example

type Response = 
  | { status: "success"; data: { /* deeply nested */ } }
  | { status: "error"; message: string };

// Depth 1: only validates discriminator field
if (typia.isShallow<Response>(input, 1)) {
  // Fast type narrowing
}

// Full validation when needed
if (typia.is<Response>(input)) {
  // All fields validated
}

Depth levels:

• 1: Top-level properties only (discriminator checks)
• 2: Default, one level of nesting
• 3+: Progressively deeper validation
• undefined: Full validation (same as typia.is)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Feature: Shallow .is checks or any "cheaper" discriminator check</issue_title>
<issue_description>There are two common use cases for .is: validation and discrimination.

Typia is often overkill for discrimination due to the amount of code it can generate for something like a JSON Schema type. For discrimination, we often don't need to validate the entire object. If there is a discriminator key, for instance, often all standard TS does is check the value of that key.

Ideally, typia could define a minimal type check to have a discriminator check based on the possible incoming types, but as I think the complexity of that is likely too high, I'm suggesting a MaxDepth param on .is or similar:

typia.is<T, N>

// or a new method to avoid over confidence

typia.isLikely<T, N=2> // 2 seems like a good default
typia.matchesToDepth<T, N=2>
```</issue_description>

<agent_instructions>Transform almost same code like `typia.is<T>()`, but limit the iteration depth.

You can do it by referencing both `CheckerProgrammer` and `IsPrrogrammer`.</agent_instructions>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>

• Fixes Feature: Shallow .is checks or any "cheaper" discriminator check #1708

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​types/​prettier@​3.0.0
	@​rollup/​browser@​4.13.0
	@​types/​body-parser@​1.19.5 ⏵ 1.19.6
	@​types/​express@​4.17.21 ⏵ 4.17.25
	@​typescript-eslint/​parser@​8.30.1 ⏵ 8.52.0
	@​types/​autocannon@​7.12.6 ⏵ 7.12.7	+1		+1
	path@​0.12.7
	nextra@​4.6.1
	process@​0.11.10
	write-file-webpack-plugin@​4.5.1
	nextra-theme-docs@​4.6.1
	embed-typescript@​1.3.2
	@​types/​inquirer@​8.2.10 ⏵ 8.2.12
	tinyglobby@​0.2.13 ⏵ 0.2.15			-14
	@​rspack/​cli@​1.7.1
	@​types/​react@​18.3.27
	@​rspack/​core@​1.7.1
	@​typescript-eslint/​eslint-plugin@​8.30.1 ⏵ 8.52.0	+1		+1
	next-sitemap@​4.2.3
	@​types/​node@​22.14.1 ⏵ 18.19.130
	@​types/​node@​22.14.1 ⏵ 20.19.27
	@​types/​node@​22.14.1 ⏵ 22.19.3	+1		+1
	@​emotion/​styled@​11.14.1
	fp-ts@​2.16.10 ⏵ 2.16.11
	gh-pages@​5.0.0
	next@​15.5.9
	rollup-plugin-node-externals@​8.0.0 ⏵ 8.1.2				-2
	@​emotion/​react@​11.14.0
	react@​18.3.1
	ts-loader@​9.5.4
	@​monaco-editor/​react@​4.7.0
	class-validator@​0.14.1 ⏵ 0.14.3	+1		+1
	tgrid@​1.2.1
See 17 more rows in the dashboard

View full report