feat(csv): add parseLine() convenience for single-line CSV records (refs #3765)

[MukundaKatta]

Summary

Refs #3765. Adds parseLine(line: string, options?: ParseLineOptions): string[] — a small synchronous convenience for single-record CSV input. Defaults to comma separator, no trim, strict quotes. Strips leading BOM and a single trailing CR/LF/CRLF.

API

parseLine("a,b,c")                       // ["a", "b", "c"]
parseLine("a\tb", { separator: "\t" })   // ["a", "b"]
parseLine('"a,b","c"')                   // ["a,b", "c"]

Documents the trade-off vs full parse() — parseLine doesn't continue multi-line quoted fields, doesn't validate field count across records, and doesn't honor comment lines. For those use parse.

Files changed

• csv/parse.ts — new ParseLineOptions interface and parseLine() function. Reuses internal Parser class. No breaking changes to existing parse() signature.
• csv/parse_test.ts — 12 new sub-steps covering basic parsing, quoting, escaped quotes, custom separator (TSV), trimLeadingSpace, lazyQuotes, trailing newline strip, BOM strip, error case, and return-type assertion.

Test plan

• deno fmt, deno lint, deno check, deno test all clean
• 11 passed, 0 failed (205 steps)
• Doc tests pass

[CLAassistant]

All committers have signed the CLA.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.61%. Comparing base (e356559) to head (960a7da).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7114   +/-   ##
=======================================
  Coverage   94.61%   94.61%           
=======================================
  Files         633      633           
  Lines       51777    51790   +13     
  Branches     9324     9330    +6     
=======================================
+ Hits        48987    49000   +13     
  Misses       2216     2216           
  Partials      574      574           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bartlomieju]

Thanks for the PR! Appreciate the thorough tests and documentation.

However, this needs significant rework. The main concern is that this doesn't match issue #3765's intent. That issue asks for parseLine as an internal primitive that parse() and CsvParseStream build on top of — a simplification/refactoring of the CSV internals. This PR does the opposite: it wraps the existing Parser class as an external convenience. It doesn't simplify anything internally; it just adds API surface area.

See inline comments for the implementation-level issues.

[bartlomieju]

ParseLineOptions manually re-declares separator, trimLeadingSpace, and lazyQuotes — fields that already exist on ReadOptions. This creates a maintenance burden (if ReadOptions changes, this must stay in sync). If this moves forward, this should be Pick<ReadOptions, "separator" | "trimLeadingSpace" | "lazyQuotes"> instead.

[bartlomieju]

This BOM stripping is redundant — Parser.parse() already strips the BOM internally (line 208). The double-strip is harmless but suggests the internals weren't fully reviewed.

[bartlomieju]

This trailing newline stripping is also redundant — Parser.#readLine() already treats \r\n, \n, and \r as line terminators. A trailing newline just produces an empty second record, which Parser.parse() drops (empty records are not pushed to the result array).

[bartlomieju]

This allocates a new Parser instance on every call. For a function named parseLine that users will naturally reach for in a loop over pre-split lines, this is wasteful — the constructor sets up options, and .parse() runs separator validation each time.

[bartlomieju]

New public APIs in std typically go through an unstable phase with an @experimental tag. This adds a stable API directly — should either be marked @experimental or get explicit maintainer sign-off to ship stable.

[MukundaKatta]

@bartlomieju thanks for the detailed review. You're right — this missed the actual ask in #3765. parseLine as a thin external wrapper around Parser adds API surface without simplifying the internals, which is the opposite of what the issue wants.

The right shape is parseLine as the underlying primitive that parse() and CsvParseStream build on (with TextLineStream upstream of the stream). That's a meaningful refactor of Parser and parseRecord, not a follow-up patch on top of this diff.

Closing this and will open a fresh PR once the refactor is sketched out properly. Inline points (Pick on options, redundant BOM/newline strips, allocating Parser per call, @experimental) all noted for the next pass.