fix(core): respect log level in worker threads

[zeexzeex]

What

--log-level had no effect on warnings coming from worker threads.

npx @doc-kit/cli generate -t web -o out -i <node>/doc/api/ --log-level fatal

printed 81 WARN lines instead of none.

Why

The level is applied on the main thread only. Worker threads load their own module graph, so the default logger export creates a separate instance there that keeps the default info level. The warnings in the report come from resolveTypes.mjs, which runs inside the workers.

The same input makes it clear:

Input	Workers used	default level	--log-level fatal
single file	no	6 WARN	0 WARN
directory (doc/api/)	yes	81 WARN	81 WARN

Both inputs produce warnings, but only the single file respects the requested level. parallel.mjs skips the pool when threads <= 1 || items.length <= 2, so running the directory with --threads 1 silences the warnings as well.

How

The level is passed through Piscina workerData and applied at the worker entry point. This adds a small getLogLevel() accessor, as there was no way to read the configured level back.

I also considered putting the level into configuration, which already reaches the workers, but createTask deliberately narrows what it sends:

// Only pass the needed configuration to this generator
configuration: {
  [generatorName]: configuration[generatorName],
},

Sending the level that way would repeat it for every chunk, while workerData is sent once per worker.

Verification

Case	Before	After
--log-level fatal	81 WARN	0 WARN
default level	81 WARN	81 WARN

The default level is unchanged, so nothing is silenced that should not be. Full suite passes (560 tests), lint and format checks are clean.

Fixes: #1032

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
api-docs-tooling	Ready	Preview	Aug 27, 2026 7:49am

[AugustinMauroy]

could you add some test

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.67%. Comparing base (18b9423) to head (68d67ac).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1058   +/-   ##
=======================================
  Coverage   89.67%   89.67%           
=======================================
  Files         205      205           
  Lines       19208    19224   +16     
  Branches     1795     1795           
=======================================
+ Hits        17224    17240   +16     
  Misses       1976     1976           
  Partials        8        8           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

api-links Generator

Performance estimate _{(single CI run)}

• Generation time: 6.3% slower (1.28 s → 1.36 s)
• Peak memory: 2.6% higher (351.06 MB → 360.26 MB)

legacy-html Generator

Performance estimate _{(single CI run)}

• Generation time: 20.8% slower (17.28 s → 20.88 s)
• Peak memory: 4.4% lower (2.38 GB → 2.28 GB)

legacy-json Generator

Performance estimate _{(single CI run)}

• Generation time: 26.5% slower (7.28 s → 9.21 s)
• Peak memory: 0.9% lower (1.79 GB → 1.77 GB)

llms-txt Generator

Performance estimate _{(single CI run)}

• Generation time: 16.4% faster (9.64 s → 8.06 s)
• Peak memory: 3.5% higher (1.74 GB → 1.81 GB)

orama-db Generator

Output size: 1 file changed · net +1.15 KB

File size details

File	Main	PR	Change
orama-db.json	9.18 MB	9.18 MB	+1.15 KB (+0.0%)

Performance estimate _{(single CI run)}

• Generation time: 1.6% slower (8.32 s → 8.45 s)
• Peak memory: 4.6% higher (1.80 GB → 1.89 GB)

web Generator

Performance estimate _{(single CI run)}

• Generation time: 23.4% faster (87.03 s → 66.68 s)
• Peak memory: 2.1% higher (4.74 GB → 4.84 GB)

[zeexzeex]

@AugustinMauroy Added tests.

getLogLevel() has unit tests, and the propagation itself is covered in threading/__tests__/index.test.mjs. The second test runs a real worker pool with a fixture generator that reports the level it sees inside the worker, so it fails if the level stops crossing the thread boundary.

I checked that they actually catch this: reverting the workerData line makes both propagation tests fail, while the default level case keeps passing.