Skip to content

Migrate remaining core package .js files (e.g. lib/markdown-it/*.js) to TypeScript and Upgrade Dependencies #2745

Description

@gerteck

TLDR: Migrate all core files to TypeScript to faciliate future switch from CommonJS (require/module.exports) to ESM (import/export) for consistency, type safety, and modern dependency support.

Is your feature request related to a problem? Please describe.

Currently, in #1913 we migrated the core package and most of its associated files to TypeScript, but left the files under lib/markdown-it/plugins as .js using CommonJS (require/module.exports).

Reasons to migrate these plugins to TypeScript now

  1. Uniformity and consistency

    • The rest of the core package is now TypeScript. Keeping these plugins in JS breaks consistency and makes the codebase harder to maintain.
  2. ESM interoperability

    • Some modern dependencies are ESM-only. Migrating plugins to TypeScript (and using import/export) facilitates smooth interop without relying on workarounds like dynamic import() or mixed module handling.
  3. Type safety and better tooling

    • TypeScript provides static type checking, IDE auto-completion, and easier refactoring. Migrating these plugins improves developer experience and reduces the risk of runtime errors.
  4. Future-proofing

    • As Node.js and modern tooling increasingly favor ESM, converting these plugins now reduces future migration pain and ensures compatibility with upcoming libraries and tooling
  5. Dependency updates

    • Some plugins rely on older JS-only versions of dependencies (e.g., htmlparser2 v3). Migrating to TypeScript allows us to upgrade to newer versions that include types and ESM support, improving maintainability and ecosystem compatibility.

Proposed plan

  • Convert lib/markdown-it/plugins/*.js*.ts.
  • Replace require/module.exports with import/export.
  • Add TypeScript types where applicable.
  • Update associated test files to .ts if necessary.
  • Upgrade plugin dependencies to their latest ESM/TypeScript-compatible versions.

Impact

  • No functional change; purely a migration for consistency, type safety, ESM interoperability, and future compatibility.

Describe the solution you'd like

Do the necessary

Describe alternatives you've considered

No response

Additional context

No response

Metadata

Metadata

Type

No type
No fields configured for issues without a type.

Projects

Status
Discussion

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions