[thecotne]

Fixes #1699

What

onUndeclaredKey("delete") and onUndeclaredKey("reject") now handle undeclared keys named after Object.prototype members (toString, valueOf, constructor, hasOwnProperty, ...) and an own __proto__ key (as JSON.parse creates) like any other undeclared key. Before, they were kept or accepted.

const T = type({ a: "string" }).onUndeclaredKey("delete")
T({ a: "x", toString: 1 }) // now { a: "x" }, was { a: "x", toString: 1 }

Why

declaresKey and the compiled _compileDeclaresKey check k in propsByKey, and propsByKey was a plain object, so in found inherited members, and "__proto__" in {} is always true.

The fix builds propsByKey as a prototype-free record (Object.create(null)), the same approach as #1586 and #1121, so k in propsByKey stays as it is in both paths. I didn't use Object.hasOwn(propsByKey, k), for two reasons:

• Object.hasOwn is ES2022 and the repo compiles with lib: ["ES2020"].
• flatMorph's result[k] = v turns a declared __proto__ key into the record's prototype, so hasOwn would make that key count as undeclared. I tried it locally and the "can be declared" tests below failed.

Writing into a null-prototype object stores __proto__ as an own key, so declared __proto__ keys keep working.

Tests

In ark/type/__tests__/objects/onUndeclaredKey.test.ts, the new tests cover:

• toString, valueOf, constructor and hasOwnProperty are deleted with "delete" and reported as must be removed with "reject".
• An own __proto__ key from JSON.parse is handled the same way.
• Declared toString and declared own __proto__ keys are still kept under both modes, and other extra keys are still rejected.
• Each case runs with JIT and with jitless: true.

Checklist:

• Code is up-to-date with the main branch (based on c34bf69)
• You've successfully run pnpm prChecks locally
• There are new or updated unit tests validating the change

Not addressed here, possibly a follow-up: required, optional and default presence checks on the data side also use in. So type({ "toString?": "string" })({}) fails with toString must be a string (was an object).

[pullfrog]

✅ No new issues found.

Reviewed changes

• Prototype-free propsByKey — StructureNode.propsByKey is now built into an Object.create(null) record via reduce instead of flatMorph. Both declaresKey and the compiled _compileDeclaresKey still evaluate k in propsByKey, but the null prototype means inherited Object.prototype members (toString, valueOf, constructor, hasOwnProperty, ...) and an own __proto__ key no longer read as declared, while a declared __proto__ is still stored as an own key.
• Regression tests — new keys named after Object.prototype members block covers delete and reject for prototype-named keys and for an own __proto__ from JSON.parse, plus declared toString/__proto__, running under both JIT and jitless: true.

I verified the full suite (1795 passing) and confirmed the two new are undeclared cases fail against the unpatched source, so they genuinely pin the bug.

ℹ️ Prototype-named presence checks remain deferred

The data-side presence checks still use in (defaultable at structure.ts:981, and the optional/required handling), so type({ "toString?": "string" })({}) still reports toString as present and fails. This PR correctly scopes to the undeclared-key path and the author already tracks the remainder, so no action is needed here — just noting it so it isn't re-flagged.

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}

[ssalbdivad]

thanks @thecotne, great find! swapped the reduce for Object.fromEntries + setPrototypeOf so it stays a one-liner and declared __proto__ keys still work, then merged