feat(sparql-anything): report each chunk as it is converted

[ddeboer]

A conversion says nothing for as long as it takes – a quarter of an hour over eighteen chunks for the GeoNames dumps – and the first sign of life is either the output file or a rejection naming one chunk. That is the one thing the port cannot work around from outside, because only the converter knows how many chunks there are and when each finishes.

new SparqlAnythingConverter({
  jarPath, workDir, taskRunner,
  onChunkConverted: ({ index, total, chunk }) =>
    console.log(`Converted ${index}/${total}${chunk ? `: ${chunk}` : ''}`),
});

Called once per chunk, in the order they finish rather than the order they were given, and not at all for a chunk that failed – that arrives as the rejection. A callback that throws aborts the run, like any other failure.

Why a callback, and not ProgressReporter

Every event in @lde/pipeline's ProgressReporter is dataset-shaped: datasetsSelected, datasetStart, distributionProbed, importStarted, distributionValidated. There is no "progress within a unit of work" event, so chunk progress has nothing to be – it would mean inventing a pipeline event for a package the pipeline does not know about.

The dependency also runs the wrong way. This package depends on @lde/task-runner and tslib; taking a ProgressReporter would either couple it to @lde/pipeline – which pipeline plugins depend on, and this is not one – or duplicate that interface, which is the same coupling with a second copy to drift.

A callback is also the shape a configurable runtime wants. Options split into configuration, which is plain data a YAML or TS document can hold (queryFile, chunks, load, heap, cliArgs, concurrency), and collaborators and wiring, which only a runtime can supply. This package has exactly one collaborator today, taskRunner, and progress reporting is the second piece of wiring – injected, never declared. Keeping that split means a runtime needs one rule rather than a bespoke deserialiser per component.

If #18 ever makes SPARQL Anything a pipeline stage, that stage adapts: it knows the dataset, so it maps chunk progress onto whatever event the pipeline gains then. Three lines, in the place whose job is translation.