Node Data-Processing CLI

Scenario

Build a Node command-line tool that transforms a data file — CSV to JSON, log filtering, a data aggregation/report, or a similar transformation of your choice — runnable as node cli.js input.csv output.json, with configuration via command-line flags.

Requirements

Core

• The tool reads an input file, transforms it, and writes an output file, with meaningful flags for at least one configuration option (an output format, a filter condition, a field mapping).
• Invalid input (a missing file, malformed data, a missing required flag) produces a clear error message and a non-zero exit code — never a raw, unhandled stack trace as the only feedback.
• The tool’s core transformation logic is factored into pure, independently unit-tested functions (recall Testing and Maintainability), separate from the file-I/O and CLI-argument-parsing code around them.
• A --stream (or similarly named) option processes the input as a stream (recall Streams) instead of reading it entirely into memory — demonstrated working correctly on an input too large to comfortably load whole, or at minimum architected so it would.
• package.json documents the tool’s usage (a bin entry, a README with example invocations), and its dependencies versus devDependencies are correctly separated (recall package.json and package-lock.json).

Stretch

• A --watch mode that re-runs the transformation when the input file changes.
• A progress indicator for the streaming path on a large file.
• Publish-ready structure: a documented exports field (recall package.json exports), even if never actually published.

Reflect

• What’s the actual performance difference between your whole-file and streaming code paths on a large input — measured, not assumed? Record the comparison (even a rough one) as part of your documentation.
• Which parts of your CLI were hardest to unit test, and why? Did dependency inversion (recall Testing and Maintainability) help, or would a different factoring have helped more?

Suggested milestones

1. A minimal version: hard-coded input/output paths, one transformation, no flags, no tests.
2. Add real CLI argument parsing and at least one configuration flag.
3. Extract the transformation logic into pure, tested functions.
4. Add robust error handling for missing/malformed input.
5. Add the streaming code path and compare its performance against the whole-file version on a large input.
6. Write the package documentation.

Acceptance checks

• Running the tool with a missing input file produces a clear error message and a non-zero exit code, not a stack trace.
• The core transformation functions have unit tests covering at least one typical case and one boundary case (an empty input, a single-row input).
• The --stream path and the default path produce identical output for the same input.
• A new contributor could run the tool successfully using only the README’s documented usage.