Hi @cenk1cenk2, hope you're well! 👋

Replication of the Problem

import { ListrTask /* ✅ error as expected with `verbatimModuleSyntax: true` */ } from 'listr2';
import { ListrTaskWrapper, /* 💥 no error as expected with `verbatimModuleSyntax: true` */ } from 'listr2';

TypeScript Playground

Problem

TaskWrapper is exposed as a runtime class in the typings, but isn’t exported as a value from dist/index.js or dist/index.cjs, meaning that verbatimModuleSyntax misses reporting it as a problem if there is no type in the import.

This leads to a situation where consumers can (incorrectly) import it as a value and receive a SyntaxError at runtime (eg. with Node.js v22.18.0 type stripping):

$ node index.ts
import { Listr, ListrTaskWrapper } from 'listr2';
                ^^^^^^^^^^^^^^^^
SyntaxError: The requested module 'listr2' does not provide an export named 'ListrTaskWrapper'
    at ModuleJob._instantiate (node:internal/modules/esm/module_job:228:21)
    at async ModuleJob.run (node:internal/modules/esm/module_job:335:5)
    at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:647:26)
    at async file:///Users/k/p/project/index.ts

Node.js v22.18.0

Suggested resolution

Maybe make the public surface type-only (export a ListrTaskWrapper interface/type; keep the concrete class internal), eg. export type { ListrTaskWrapper } from the entry and stop re-exporting/mentioning the class in public types.

Environment

OS: macOS Sequoia 15.6 (24G84)
Node.js version: v22.18.0
Terminal: Ghostty 1.1.3
listr2 version: 9.0.1

Log Output

Preflight

• Read/Search existing issues and the provided documentation.
• Be sure to not open an issue in the looking for contributions section.
• Checking the latest version of the software to confirm it has not been fixed already.