I added assertType here because I think this is a very good document for users given that the return type varies depending on the option we pass in.

While I was writing these assertions, though, I was unsure in what cases the value in the return value becomes undefined. Does anyone know why we have Record<string, string | undefined> instead of Record<string, string> here?

I think you can get an undefined value if you had the following input a,b,c\nd,,f. Perhaps, we should add another test for that case.

I tried the following three test cases and these pass. I couldn't find a case where the parsed value becomes undefined

    await t.step({
      name: "BlankField2",
      fn() {
        const input = "a,b,c\nd,,f";
        assertEquals(
          parse(input, { skipFirstRow: true }),
          [{ a: "d", b: "", c: "f" }],
        );
      },
    });

    await t.step({
      name: "Exessive fields with skipFirstRow: true",
      fn() {
        const input = "a,b,c\nd,,f,g";
        assertThrows(
          () => parse(input, { skipFirstRow: true }),
          Error,
          "Error number of fields line: 1\nNumber of fields found: 3\nExpected number of fields: 4",
        );
      },
    });

    await t.step({
      name: "Insufficient fields with skipFirstRow: true",
      fn() {
        const input = "a,b,c\nd,e";
        assertThrows(
          () => parse(input, { skipFirstRow: true }),
          Error,
          "Error number of fields line: 1\nNumber of fields found: 3\nExpected number of fields: 2",
        );
      },
    });

Added (or fixed the existing) tests on what happens if the number of fields in records doesn't match that of the header. This fix contains the change in how we display the line number is error messages (which was 0-based but now changed to 1-based).

a91806b

I think you can get an undefined value if you had the following input a,b,c\nd,,f. Perhaps, we should add another test for that case.

Is there a reason there's an option to trim only leading spaces? Why not just trim the end too using String.prototype.trim()?

I'm not sure either, but according to the head comment of parse.ts, many parts of the implementation was ported from Go which has the same option.
https://github.com/golang/go/blob/go1.12.5/src/encoding/csv/reader.go#L136

I can't think of a reason to only trim the start... I suggest changing to trim: boolean. Not a strong opinion. What do we think?

Asked ChatGPT, it answered some application may add leading whitespaces when exporting to CSV. I don't know if this is true at all 😄 Anyway trim: boolean should be useful in some scenarios and I think we could add that after 1.0 without breaking things?

I think trailing spaces are usually considered as a part of value of the last column (For example, excel handles it in that way)

I couldn't find the case when this returns Record<string, string | undefined>, but I also noticed that fieldsPerRecord option doesn't seem working as described.

It says:

If negative, no check is made and records may have a variable number of fields.

But parse doesn't seem allowing wrong number of fields even when I passed negative number to this option. Maybe this current state is related to it?

But parse doesn't seem allowing wrong number of fields even when I passed negative number to this option. Maybe this current state is related to it?

Oh that's a good find. I'll add a test case and fix it