feat: implement error() factory function

[martyy-code]

Summary

Implement the error() factory function, the core building block of @deessejs/errors.

• Creates typed, structured errors following Standard Schema specification for field definitions
• Supports single and multiple inheritance via ErrorFactory references
• Message templates with {field} placeholders and :upper/:lower/:json modifiers
• Full ErrorInstance with all required properties (name, message, stack, fields, notes, cause, causes, context, httpStatus)

Test Plan

• 36 unit tests passing covering all acceptance criteria:
  • Basic usage
  • ErrorInstance properties
  • inherits option (single and multiple)
  • Message templates
  • httpStatus
  • Standard Schema support
  • Type inference
  • Factory identity
  • Stack traces
• TypeScript type-check passes
• ESLint passes
• Build succeeds

🤖 Generated with Claude Code

[codewizdave]

Do not want theses two

[codewizdave]

maybe template is usefull

[codewizdave]

same, remove

[codewizdave]

remove pls

[codewizdave]

maybe template is usefull

[codewizdave]

should have it's own type

[codewizdave]

what is this ?

[martyy-code]

PR Review: feat: implement error() factory function

Summary

A solid foundation for the error factory pattern. The implementation is clean and the type safety with generics is well-done. However, there are several issues that need addressing before this can be considered production-ready.

---

Critical Issues

1. in dependencies (not devDependencies)
The diff shows was added as a regular , not . This is unusual and will bloat the installed package size for consumers. TypeScript type packages should never be runtime dependencies.

Fix:

"devDependencies": {
"@types/node": "^25.9.1",
...
}

**2. Type/Implementation Mismatch: , , , **
The interface includes , , , and , with JSDoc referencing methods like and . However, these are never initialized with usable values (always empty arrays, null) and no methods exist to populate them. This creates an incomplete API that doesn't match the documented intent.

3. Template skips formatting when no fields provided (line 152)
The condition means calling with an empty string will skip formatting entirely. An empty string is a valid field value that should still trigger template substitution.

---

Suggestion Issues

**4. Inconsistent underscore prefix on **
Factory has (no underscore, line 31-32 of types) but ErrorInstance has (with underscore, line 56). This inconsistency suggests different naming conventions for what should be the same concept. Consider either:

• Both with underscore: on factory, on instance
• Neither with underscore: on both

5. is V8-specific
The implementation assumes V8 stack format with comments acknowledging "V8 engines provide Error.stack". While this works in Node.js and modern browsers, it will break in Deno or other JavaScript runtimes. Consider adding a fallback or at least documenting this limitation.

6. Stack cleaning uses fragile string matching
Filtering frames via could miss bundled versions of the library or paths with different casing. Consider a more robust approach using regex patterns or URL normalization.

7. Missing method
The PR description mentions "ErrorInstance with all required properties" but a common pattern for error factories is a method that actually throws the error. This is missing and may be expected by users.

---

DX Positives

praise: The factory function pattern with generics () is excellent TypeScript usage
praise: Multiple inheritance via array is a thoughtful design choice
praise: Message template modifiers (, , ) are a nice DX touch
praise: Test coverage is comprehensive with 36 tests
praise: The interface is clean and correctly structured

---

Questions

1. Are , , and context injection planned for future PRs? The types suggest they are, but they're not implemented.
2. Should the factory itself extend so checks work?
3. Is the V8-only stack trace intentional for the initial release?

[martyy-code]

PR Review: feat: implement error() factory function

Summary

A solid foundation for the error factory pattern. The implementation is clean and the type safety with generics is well-done. However, there are several issues that need addressing before this can be considered production-ready.

---

Critical Issues

1. @types/node in dependencies (not devDependencies)
The package.json diff shows @types/node was added as a regular dependencies, not devDependencies. This is unusual and will bloat the installed package size for consumers. TypeScript type packages should never be runtime dependencies.

2. Type/Implementation Mismatch: notes, cause, causes, context
The ErrorInstance interface includes notes: string[], cause: Error | null, causes: Error[], and context: Record<string, unknown> | null, with JSDoc referencing methods like .addNote() and .from(). However, these are never initialized with usable values (always empty arrays, null) and no methods exist to populate them. This creates an incomplete API that doesn't match the documented intent.

3. Template skips formatting when no fields provided (line 152)
The condition Object.keys( fieldsData ).length > 0 means calling ValidationError({ field: '' }) with an empty string will skip formatting entirely. An empty string is a valid field value that should still trigger template substitution.

---

Suggestion Issues

4. Inconsistent underscore prefix on _inherits
Factory has inherits (no underscore, line 31-32 of types) but ErrorInstance has _inherits (with underscore, line 56). This inconsistency suggests different naming conventions for what should be the same concept.

5. captureStack is V8-specific
The implementation assumes V8 stack format with comments acknowledging "V8 engines provide Error.stack". While this works in Node.js and modern browsers, it will break in Deno or other JavaScript runtimes. Consider adding a fallback or at least documenting this limitation.

6. Stack cleaning uses fragile string matching
Filtering frames via !line.includes( 'node_modules/@deessejs' ) could miss bundled versions of the library or paths with different casing. Consider a more robust approach using regex patterns or URL normalization.

7. Missing throw() method
The PR description mentions "ErrorInstance with all required properties" but a common pattern for error factories is a .throw() method that actually throws the error. This is missing and may be expected by users.

---

DX Positives

praise: The factory function pattern with generics (const T) is excellent TypeScript usage
praise: Multiple inheritance via array is a thoughtful design choice
praise: Message template modifiers (:upper, :lower, :json) are a nice DX touch
praise: Test coverage is comprehensive with 36 tests
praise: The ErrorFactory interface is clean and correctly structured

---

Questions

1. Are .addNote(), .from(), and context injection planned for future PRs? The types suggest they are, but they're not implemented.
2. Should the factory itself extend Error so instanceof checks work?
3. Is the V8-only stack trace intentional for the initial release?

[martyy-code]

blocking: Line 152 in error.ts has a logic bug in template formatting.

The condition:

if(message&&Object.keys(fieldsData).length>0){

This means calling an error factory with an empty string value will skip template formatting:

constValidationError=error({name: 'V',message: 'Field "{field}" is invalid'});ValidationError({field: ''});// message stays as 'Field "{field}" is invalid'

An empty string is a valid field value. The fix should check for the existence of the key, not the truthiness of the value:

consthasFields=Object.keys(fieldsData).length>0||Object.values(fieldsData).some(v=>v!==undefined);if(message&&hasFields){

Or alternatively, pass a special marker when you want raw template output.

[martyy-code]

blocking: @types/node should be in devDependencies, not dependencies.

In package.json, @types/node is listed under dependencies. This is incorrect because:

• @types/node provides TypeScript type definitions, not runtime code
• It should only be used during development (compilation)
• Including it as a runtime dependency unnecessarily increases installation size for all consumers

Move it to devDependencies:

"devDependencies": {
"@types/node": "^25.9.1",
...
}

[martyy-code]

suggestion: The ErrorInstance type defines notes, cause, causes, and context properties but no way to populate them.

The types show:

• notes: string[] (with JSDoc referencing .addNote())
• cause: Error | null (with JSDoc referencing .from())
• causes: Error[]
• context: Record<string, unknown> | null

But the implementation only ever sets:

• notes: [] (always empty array)
• cause: null (never set)
• causes: [] (always empty array)
• context: null (never set)

This creates an API surface that promises functionality that doesn't exist. Options:

1. Implement the missing methods (.addNote(), .from()) in this PR
2. Remove these properties from the interface until they're implemented
3. Add TODO comments explicitly marking these as unimplemented

The current state is misleading to consumers who will see these properties exist but can't actually use them.