Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Behavior changes and types are incorrect based on intersection array order #684

Open
Ethan826 opened this issue Jan 24, 2023 · 1 comment

Comments

@Ethan826
Copy link

Ethan826 commented Jan 24, 2023

🐛 Bug report

When using t.intersection, the correctness of the types/behavior is affected by the order of the codecs in the array.

Current Behavior

I get no type error in circumstances in which the code fails at runtime (see the example below).

Expected behavior

I expected that if it's intentional that the order of elements in intersection is meaningful, that would be reflected in the types, or if it isn't, that the order of arguments wouldn't matter in runtime behavior.

Reproducible example

import * as E from "fp-ts/Either";
import { pipe } from "fp-ts/function";
import * as O from "fp-ts/Option";
import * as t from "io-ts";
import { DateFromUnixTime, optionFromNullable } from "io-ts-types";

describe("bug with types", () => {
  it("infers types incorrectly", () => {
    const SomeCodec = t.intersection([
      t.type({ date: optionFromNullable(DateFromUnixTime) }),
      t.record(t.string, optionFromNullable(t.unknown)),
    ]);

    const result = SomeCodec.decode({ date: 367722000, dog: "cat" });
    
    // No type error but it throws
    expect(() =>
      pipe(
        result,
        E.map(({ date }) =>
          pipe(
            date,
            // `d` isn't actually a date here. It's a number (like the input)
            O.map((d) => d.toISOString())
          )
        )
      )
    ).toThrow(TypeError);
  });

  it("infers types correctly with a different order", () => {
    const SomeCodec = t.intersection([
      // Move this up
      t.record(t.string, optionFromNullable(t.unknown)),
      t.type({ date: optionFromNullable(DateFromUnixTime) }),
    ]);

    const result = SomeCodec.decode({ date: 367722000, dog: "cat" });

    expect(() =>
      pipe(
        result,
        E.map(({ date }) =>
          pipe(
            date,
            O.map((d) => d.toISOString())
          )
        )
      )
    ).not.toThrow(TypeError);
  });

  it("infers types correctly without `optionFromNullable`", () => {
    const SomeCodec = t.intersection([
      t.type({ date: optionFromNullable(DateFromUnixTime) }),
      t.record(t.string, t.unknown),
    ]);

    const result = SomeCodec.decode({ date: 367722000, dog: "cat" });

    expect(() =>
      pipe(
        result,
        E.map(({ date }) =>
          pipe(
            date,
            O.map((d) => d.toISOString())
          )
        )
      )
    ).not.toThrow(TypeError);
  });
});

Suggested solution(s)

I suspect there is some kind of unintended effect of ordering in intersection.

Your environment

I just wrote the code that does this today so haven't seen it fail or succeed with other io-ts versions.

Software Version(s)
io-ts 2.2.20
fp-ts 2.13.1
io-ts-types 0.5.19
TypeScript 4.7.4
@dspasojevic
Copy link

This also seems to affect 2.2.21.

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

No branches or pull requests

2 participants