v4.0.4

Summary

Release meta

Released on: 2026-07-15
Released by: ggrossetie
Published by: GitHub

Logs: full diff

Changelog

Improvements

• Declare the instance form ("style 3") of the Registry extension registration methods in the TypeScript typings. The runtime has always accepted an already-constructed processor (registry.includeProcessor(new MyIncludeProcessor())) in addition to the class and registration-function forms, but the 4.0 typings only declared the latter two, forcing consumers such as the VS Code AsciiDoc extension to augment the module by hand. preprocessor, treeProcessor, postprocessor, includeProcessor, docinfoProcessor, block, blockMacro and inlineMacro now expose an overload accepting a processor instance (the syntax processor methods also accept the optional explicit name), and the compile-only type tests cover the instance form
• Type the filter callback accepted by AbstractBlock#findBy (and its query alias) as (node: AbstractBlock) => boolean | string instead of the bare Function, so the candidate node passed to the callback resolves as an AbstractBlock without casts — both in the two-argument form and in the findBy(callback) shorthand
• Type the reader received by preprocessor and include processor callbacks as PreprocessorReader instead of Reader, and export PreprocessorReader from the package root. Preprocessor#process, IncludeProcessor#process and the matching DSL process(fn) callbacks actually receive a PreprocessorReader at runtime, so its members (pushInclude, getIncludeDepth, …) now resolve without casts or manual module augmentation

Infrastructure

• Display the package version number in the generated TypeDoc API documentation (includeVersion option), so both the @asciidoctor/core API docs and the asciidoctor CLI docs show which release they document (e.g. @asciidoctor/core - v4.0.3)
• Publish a major.minor alias of the TypeDoc API documentation on each stable release — e.g. releasing v4.0.4 (re)deploys the docs to both 4.0.4/ and 4.0/ on GitHub Pages, so the 4.0 URL always points to the documentation of the latest 4.0.x release
• Simplify the release workflow: the intermediate "Bump version for release" workflow (release-bump.yml) is gone — the Release workflow is now dispatched directly with the version to release and performs the whole chain (bump + tag, build, npm publish, GitHub release, docs) in a single run, from main or from a maintenance branch (e.g. 4.0.x or v4.0.x). The git commands (commit, tag, push) live in the workflow itself; the release scripts are reduced to three focused tools: tasks/version.js <version> (sets both package versions and keeps the asciidoctor → @asciidoctor/core dependency in sync), tasks/changelog.js release <version> (rolls the Unreleased section into a dated release section) / tasks/changelog.js notes <version> (prints the Markdown release notes of a version to stdout), and tasks/publish.js (publishes both packages to npmjs). tasks/release.js, scripts/publish.sh, the npm run release script and the skip_publish input are gone (use GitHub’s "Re-run failed jobs" to resume a partially failed release). The reusable build and native-image workflows accept a ref input so the release builds the tagged commit (with the bumped version) rather than the pre-bump branch head
• Publishing a maintenance release no longer steals the npm latest dist-tag: when the version being published is older than the currently published latest (e.g. releasing 4.0.5 while 4.1.0 is out), the packages are published under a latest-<major>.<minor> dist-tag (e.g. latest-4.0, following the latest-2 convention already used for the 2.x line) instead