Fix use of Schema.NonEmptyArrayEnsure with strings

[thewilkybarkid]

Type

• Refactor
• Feature
• Bug Fix
• Optimization
• Documentation Update

Description

Schema.NonEmptyArrayEnsure doesn't work with strings. The compiler doesn't recognise that the value being passed to Array.isNonEmptyReadonlyArray might not be an array, and the function only checks the length property which also exists on strings.

Related

• Related Issue #
• Closes #

[changeset-bot]

🦋 Changeset detected

Latest commit: 37f89d6

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
effect	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pullfrog]

Run failed. View the logs →

  ^{｜ ⚠️ this action is pinned to a commit SHA, which freezes the cleanup step — switch to @v0 or keep the SHA fresh with Dependabot ｜ Rerun failed job ➔ ｜ View workflow run ｜ via Pullfrog ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

[gcanti]

Array.ensure changes the existing behavior when the value schema itself accepts arrays. For example, an empty array is a valid single value here:

const schema = S.NonEmptyArrayEnsure(S.Array(S.String))

On v3, decoding [] produces [[]]. With Array.ensure, it remains [] and is then rejected by the target NonEmptyArray schema.

Could we preserve that behavior while also checking that non-empty values are actual arrays?

decode: (i) =>
  (Array.isArray(i) && array_.isNonEmptyReadonlyArray(i) ? i : array_.of(i)),

I would also add this regression test:

it("decode array value", async () => {
  const schema = S.NonEmptyArrayEnsure(S.Array(S.String))
  await Util.assertions.decoding.succeed(schema, [], [[]])
})

This should cover both the string fix and the previous empty-array behavior.