When the value of Record type is undefined, it should be an error, but it is not.

[ryoppippi]

Bug Report

Note that, the bug you're reporting may have registered in the issues by another user. Even the bug you're reporting may have been fixed in the @next version. In such reasons, I recommend you to check the old issues and reproduct your code with the @next version before publishing the bug reporting issue.

`npm install --save-dev typia@next`

When the same error occurs even in the @next version, then please fill the below template:

📝 Summary

Write a short summary of the bug in here.

• Typia Version: 6.1.0

⏯ Playground Link

https://typia.io/playground

Visit above playground and write code occuring the bug.

After that, copy and paste link address of that.

Example Link

https://typia.io/playground/?script=JYWwDg9gTgLgBDAnmYBDANHA3g5BTBVAcwGc4BfOAMyghDgCIkVUGBuAKA+YIBU4AvHABKeAMbQAJgB4SMKMAB2RdIoCuIAEZ4oAPg4TFcuADdB2BqwBccNYsl4qSvJMpdDx4GSHM0AOi9pXl0AChMASncIIwgAGzw-WIgiEK9wuAB6DLgSAAsINVjJOG1qVFiSAk01eHk1PC4gA

💻 Code occuring the bug

import typia, { type tags } from "typia";

type T = Record<string,number>
const v = {"a": undefined} 

const is = typia.is<T>(v)

console.log(is) // should be false but true

suggested solution.

We need to use Object.hasown instead of value[key] === undefined

Related

https://x.com/a4lg/status/1805485371494744536 by @a4lg

[a4lg]

Sorry for not reporting earlier despite being a discoverer (thanks for creating the issue @ryoppippi!).

I usually don't write web code and I am not sure how to fix... oh? Is this your intention here?

{
    "plugins": [
        {
            "transform": "typia/lib/transform",
            "undefined": false // !!!
        }
    ]
}

At least, on my particular case I'm testing, it works as expected on is but not on assert.

According to the documentation of ITransformOptions, there is an issue when validating without allowing superfluous properties.

Let me clarify the situation. The intent of this option is change the behavior of the code below, is it?

interface ISample {
    a: number;
}
export const is_ISample = typia.createIs<ISample>();
export const eq_ISample = typia.createEquals<ISample>();

/* import is_ISample, eq_ISample */
console.log(is_ISample({a: 0, b:undefined})); // true
console.log(eq_ISample({a: 0, b:undefined})); // true by default but "undefined":false makes eq_ISample return false.

I think it's type-safe and reasonable, depending on the situation.

But accepting undefined just when there is a dynamic property easily breaks type-safety. Perhaps, the target to fix is somewhere around check_dynamic_property?

[a4lg]

Hmm, is works fine after changing undefined option to false but it erroneously accepts invalid inputs with undefined props on assert. So, we need to fix something related to error-generating code as well.

[ryoppippi]

I didn't understand more about Typia OPTIONS! So there is undefined option, thank you!

[a4lg]

My opinion is clear: undefined value should not be accepted (unless the value can be undefined) when a dynamic property can match (regardless of the undefined transform option).