Player Bulk Update

[AntHill12]

sprocket/core/src/franchise/player/player.resolver.ts

Line 275 in 1bc75a6

const results = csvs.flatMap(csv => csv.split(/(?:\r)?\n/g).map(l => l.trim().split(","))).filter(r => r.length > 1);

There are no filters beyond a comma for the data uploaded in the CSV. This causes issues if a name has a comma in it. I would also say adding further filtering for special characters to either deny or allow if they appear even on accident.

[gankoji]

This problem exists elsewhere in the codebase as well, I'm fairly certain we use that hacky line anywhere we have to take CSV as input! Here's a suggestion from Gemini on how to fix:

Here is a robust, reusable generic function that combines PapaParse for the heavy lifting of text parsing and Zod for runtime type guarantees.

The parseAndValidateCsv Utility

This function takes a CSV string and a Zod schema. It returns a strictly typed array of data and a separate array of errors, ensuring your application logic never touches invalid data.

import Papa from 'papaparse';
import { z } from 'zod';

// 1. Define the shape of our output
interface CsvParseResult<T> {
  data: T[];
  errors: CsvError[];
}

interface CsvError {
  row: number;     // 1-based row index (Excel style)
  message: string; // The error message
  field?: string;  // Which column failed (if known)
  value?: any;     // The raw value that caused the error
}

/**
 * Parses a CSV string and validates rows against a Zod schema.
 * * @param csvString - The raw CSV content.
 * @param schema - The Zod schema to validate each row against.
 * @param options - Optional overrides for PapaParse config.
 */
export function parseAndValidateCsv<T extends z.ZodTypeAny>(
  csvString: string,
  schema: T,
  options: Papa.ParseConfig = {}
): CsvParseResult<z.infer<T>> {
  
  const validData: z.infer<T>[] = [];
  const errors: CsvError[] = [];

  // 1. Parse raw text to untyped objects
  const parseResult = Papa.parse(csvString, {
    header: true,           // Expect first row to be headers
    skipEmptyLines: true,   // Ignore empty lines
    dynamicTyping: true,    // Attempt to convert "123" to 123, "true" to true
    ...options,             // Allow caller to override
  });

  // 2. Handle CSV-level structural errors (e.g., malformed delimiters)
  parseResult.errors.forEach((err) => {
    errors.push({
      row: err.row + 1, // Adjust for 0-index if needed, usually Papa returns 0-index
      message: `CSV Syntax Error: ${err.message}`,
    });
  });

  // 3. Validate each row against the Schema
  parseResult.data.forEach((row, index) => {
    // Row index + 2 because: 0-indexed array + 1 for header row = actual line number
    const rowIndex = index + 2; 

    const validation = schema.safeParse(row);

    if (validation.success) {
      validData.push(validation.data);
    } else {
      // Extract detailed Zod error messages
      validation.error.issues.forEach((issue) => {
        errors.push({
          row: rowIndex,
          message: issue.message,
          field: issue.path.join('.'),
          value: (row as any)[issue.path[0]],
        });
      });
    }
  });

  return { data: validData, errors };
}

Usage Example

Here is how you would use this in a real-world scenario (e.g., uploading a user roster). Note the use of z.coerce, which is a "best practice" when dealing with CSVs to ensure strings like "100" are safely forced into numbers if dynamicTyping misses them.

import { z } from 'zod';
// import { parseAndValidateCsv } from './utils/csvParser';

// 1. Define Schema
// Use z.coerce to handle string-to-primitive conversion safely
const EmployeeSchema = z.object({
  id: z.coerce.number(), 
  username: z.string().min(3),
  email: z.string().email(),
  isActive: z.coerce.boolean(),
});

// 2. Simulating a CSV File
const csvFileContent = `id,username,email,isActive
101,jdoe,jdoe@example.com,true
102,asmith,invalid-email,false
text,bwayne,bwayne@example.com,true`;

// 3. Execute
const result = parseAndValidateCsv(csvFileContent, EmployeeSchema);

// 4. Handle Results
if (result.errors.length > 0) {
  console.log("❌ Found errors:");
  console.table(result.errors); 
  // Expect errors for:
  // Row 3: "invalid-email" (Validation Error)
  // Row 4: "text" cannot be coerced to number (Validation Error)
}

console.log(`✅ Successfully parsed ${result.data.length} records:`);
console.log(result.data); 
// result.data is typed as { id: number, username: string... }[]

Why this is the "Robust" approach:

1. Segregation: It separates valid rows from invalid rows. In many batch jobs, you want to import the 99% that worked and report on the 1% that failed, rather than aborting the whole process.
2. Type Inference: You don't have to manually define TypeScript interfaces. z.infer<typeof Schema> ensures your schema and your TS types are always perfectly in sync.
3. Detailed Reporting: The error object gives you the specific Row, Field, and Value that failed, which is critical for generating UI feedback for users uploading files.

Next Step:
Since you are likely integrating this into an application (perhaps Sprocket or an internal tool), would you like me to adjust this to handle renaming/mapping headers (e.g., mapping CSV header "First Name" to JSON property firstName) before validation?

[gankoji]

This has been fixed for the new LO mutation. PR 606 also added the csv-parse util library that can be used with other mutations.