[Bug] npm CLI `lit parse --format text` omits the `--- Page N ---` separators the cargo and pip CLIs emit
Description
All three distributions install a lit binary, but the npm one produces different
--format text output from the cargo and pip ones: it omits the --- Page N ---
separators. text is the default --format for all three CLIs, so lit parse multi-page.pdf installed from npm silently loses every page boundary.
The cargo and pip CLIs both route OutputFormat::Text through
text::format_text(&result.pages), which prefixes every page with \n--- Page N ---\n:
crates/liteparse/src/main.rs:427crates/liteparse-python/src/cli.rs:307crates/liteparse/src/output/text.rs:4
The Node CLI instead writes result.text for any non-json format
(packages/node/src/cli.ts:172, and the same in batch-parse at
packages/node/src/cli.ts:441). For --format text, ParseResult.text is the page
texts joined by \n\n with no page markers (crates/liteparse/src/parser.rs:609-613).
One thing worth flagging for whoever picks this up: result.text is the right
source for --format markdown — the Rust CLI uses result.text.clone() for that
branch — so this can't be a blanket switch to format_text(). Only the text branch
should change.
I'm happy to send a PR if you'd like it fixed this way; I opened an issue first since it changes the default stdout of a shipped CLI, and that felt like your call rather than mine.
Steps to Reproduce
Both CLIs on the same document, same flags, from a checkout of main (d2f7626,
v2.10.1):
# cargo CLI
cargo build -p liteparse --no-default-features
./target/debug/lit parse demo/docs/apple-10k-2024.pdf --no-ocr --max-pages 2 --format text -q
# npm CLI (same tree, packages/node/src/cli.ts against a locally built napi module)
node packages/node/src/cli.ts parse demo/docs/apple-10k-2024.pdf --no-ocr --max-pages 2 --format text -qResult:
| bytes | --- Page markers |
first line | |
|---|---|---|---|
cargo lit |
6801 | 2 | --- Page 1 --- |
npm lit |
6768 | 0 | UNITED STATES |
The 33-byte delta is exactly 2 x 16 (the two \n--- Page N ---\n separators) plus the
one trailing newline that println! adds and process.stdout.write does not.
Expected: the npm CLI emits the same page-delimited text as the cargo and pip CLIs. Actual: page boundaries are absent, so downstream consumers can't tell where page 1 ends and page 2 begins.
Error Message
No error — the output is silently different.
LiteParse Version
2.10.1
Operating System
macOS (Apple Silicon)
Node.js Version
v26.4.0
Additional Context
Two further divergences I noticed while checking this, which the change above would not close — flagging them so nobody assumes the two CLIs are byte-identical afterwards:
- Trailing newline: the Rust and Python CLIs use
println!, the Node CLI usesprocess.stdout.write, so the Node output is one byte shorter even ignoring the separators. - JSON float formatting differs between the surfaces (e.g.
612.0vs612).
I built the napi module locally (cargo build -p liteparse-napi --no-default-features,
copied to packages/node/liteparse.node) and ran packages/node/src/cli.ts directly
rather than installing the published npm package, so the reproduction above is against
this tree's source, not a registry install. The relevant source is unchanged between
bc43cd4 and d2f7626.
There are currently no tests over packages/node — ci-node.yml only smoke-tests
getConfig — which is presumably why this went unnoticed; #261 already tracks adding
node e2e tests.
Source: run-llama/liteparse