Decidir o futuro do pdf-parse: a v2 É o pdfjs-dist e colapsa a redundância de duas engines do RAG

[melgarafael]

O Dependabot propôs pdf-parse 1.1.4 → 2.4.5 (#213, fechado). O verify reprovou com

lib/ai/rag/extractors/pdf.ts(26,50): error TS2339: Property 'default' does not exist

porque a v2 é reescrita e exporta a classe PDFParse, não uma função default. Adaptar isso seria pequeno. O que fez o PR ser fechado é outra coisa:

"pdf-parse@2.4.5": { "dependencies": { "@napi-rs/canvas": "0.1.80", "pdfjs-dist": "5.4.296" } }

O pdf-parse@2 É o pdfjs-dist. E lib/ai/rag/extractors/pdf.ts é, por desenho, duas engines independentes:

Primary : pdf-parse
Fallback: pdfjs-dist legacy build (handles layout-heavy/scanned PDFs)

Aceitar o bump colapsa as duas na mesma engine: o fallback deixa de ser fallback, e o PDF que a v5 não lê a v6 também não lê. Medido nos lockfiles:

	pdfjs-dist
main	6.2.108
com pdf-parse@2.4.5	5.4.296 e 6.2.108 (36 MB + 34 MB)

Mais @napi-rs/canvas, que é binário nativo — assunto da imagem Docker do self-host.

A decisão

• (a) Ficar em pdf-parse@1 e manter duas engines de verdade. Custo: uma dependência parada numa major antiga.
• (b) Largar o pdf-parse e usar pdfjs-dist@6 direto (já está aqui). Aí a segunda tentativa passa a ser outra coisa, ou some conscientemente, e o pdf.ts fica honesto sobre quantas tentativas tem.

O dado que decide é qual das engines extrai melhor os PDFs reais que passam pelo RAG — e isso precisa de corpus, não de leitura de código. Enquanto ninguém medir isso, (a) é o default seguro.

Contexto que pesa: pdf.ts:45 registra que o fallback já esteve inalcançável por um return antes de ler o primeiro byte. Alguém já pagou por essa redundância não funcionar.

[melgarafael]

A decisão procede (ninguém decidiu), mas a premissa que sustenta a issue é falsa — e isso muda a recomendação. Medido em origin/main f9abedd (pdf-parse@1.1.4, pdfjs-dist@6.2.108 no lock).

Não existem duas engines. Já são a mesma, com 7 majors de distância entre elas.

$ ls node_modules/.pnpm/pdf-parse@1.1.4/node_modules/pdf-parse/lib/pdf.js/
v1.9.426  v1.10.88  v1.10.100  v2.0.550

O pdf-parse@1 vendoriza quatro cópias completas do pdf.js da Mozilla dentro de si — 29 dos 29 MB do pacote estão em lib/ — e lib/pdf-parse.js:42 fixa v1.10.100 como default, carregada em :62 por require("./pdf.js/" + options.version + "/build/pdf.js").

Confirmado em runtime:

pdf.js DENTRO do pdf-parse@1.1.4 : 1.10.100
pdfjs-dist (fallback)            : 6.2.108

Então o que o RAG tem hoje não é "duas engines redundantes": é o mesmo pdf.js duas vezes, uma delas de 2018, e a antiga é a que roda primeiro. Isso inverte o argumento da issue: o "default seguro" de ficar no pdf-parse@1 é justamente o pior dos dois lados — carrega 29 MB de código morto e a versão velha.

Vou deixar a issue aberta com a premissa corrigida, porque a decisão em si (colapsar para uma) segue valendo e agora tem um motivo mais forte do que tinha.