Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Aug 21, 2025

Template literal types were not inheriting validation tags when intersected with tags like MaxLength and Pattern. This caused validation to pass incorrectly when it should fail.

Problem

Consider this type intersection:

type TaggedTemplate = tags.MaxLength<10> & 
                     tags.Pattern<'^[a-zA-Z0-9_]+$'> & 
                     `prefix${string}postfix`;

const testValue = 'prefix;"+,df0123456789postfix'; // 28 chars, special characters

// Before fix: This would pass validation (incorrect)
typia.validate<TaggedTemplate>(testValue); // { success: true }

// But regular string with same tags would fail correctly  
typia.validate<tags.MaxLength<10> & tags.Pattern<'^[a-zA-Z0-9_]+$'> & string>(testValue); 
// { success: false, errors: [...] }

The issue affected all validation functions: validate, assert, is, and schema generation.

Root Cause

The intersection handler correctly processed validation tags and attached them to template literal metadata. However, the code generator for templates (check_template) was only generating pattern matching code and ignoring the tpl.tags field, unlike check_string which processes both type checking and validation tags.

Solution

Modified src/programmers/internal/check_template.ts to:

  1. Add validation tag processing: Created check_template_type_tags function similar to check_string_type_tags
  2. Generate validation conditions: Process tags with validate scripts and transpile them to runtime checks
  3. Combine all validations: Return conditions that include template pattern matching AND validation tag checking

Updated call sites in CheckerProgrammer.ts and check_dynamic_key.ts to pass the required context parameter.

After Fix

// Now correctly fails validation
typia.validate<TaggedTemplate>('prefix;"+,df0123456789postfix');
// { 
//   success: false, 
//   errors: [
//     { expected: "string & MaxLength<10>", ... },
//     { expected: "string & Pattern<'^[a-zA-Z0-9_]+$'>", ... }
//   ] 
// }

// Valid values pass as expected
typia.validate<TaggedTemplate>('prefix123pos'); // { success: true }

The fix ensures template literals validate against:

  1. Template structure (must match prefix*postfix pattern)
  2. Length constraints (MaxLength<10>)
  3. Pattern constraints (Pattern<'^[a-zA-Z0-9_]+$'>)

Fixes #1635.


💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Copilot AI changed the title [WIP] typia tags failed on template literal types Fix template literal validation tag inheritance in type checking Aug 21, 2025
Copilot AI requested a review from samchon August 21, 2025 23:39
Copilot finished work on behalf of samchon August 21, 2025 23:39
@samchon samchon closed this Aug 21, 2025
@samchon samchon reopened this Aug 22, 2025
@pkg-pr-new
Copy link

pkg-pr-new bot commented Aug 22, 2025

Open in StackBlitz

npm i https://pkg.pr.new/typia@1656

commit: 1891b30

Copy link

@Mlocik97 Mlocik97 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

4 .map and .filter loops instead of one reduce? I think we can optimize this.

Comment on lines +71 to +74
.map((row) => row.filter((tag) => !!tag.validate))
.filter((row) => !!row.length)
.map((row) =>
row.map((tag) => ({
Copy link

@Mlocik97 Mlocik97 Oct 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot let's replace this with one single reduce loop.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

typia tags failed on template literal types

3 participants