You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@netbeans.apache.org by "dependabot[bot] (via GitHub)" <gi...@apache.org> on 2026/07/22 01:43:22 UTC
[PR] Bump the all-dependencies group across 1 directory with 3 updates [netbeans-antora-ui]
dependabot[bot] opened a new pull request, #133:
URL: https://github.com/apache/netbeans-antora-ui/pull/133
Bumps the all-dependencies group with 3 updates in the / directory: [@asciidoctor/core](https://github.com/asciidoctor/asciidoctor.js), [js-yaml](https://github.com/nodeca/js-yaml) and [sass](https://github.com/sass/dart-sass).
Updates `@asciidoctor/core` from 4.0.0 to 4.0.5
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/asciidoctor/asciidoctor.js/releases">@asciidoctor/core's releases</a>.</em></p>
<blockquote>
<h2>v4.0.5</h2>
<h2>Summary</h2>
<h2>Release meta</h2>
<p>Released on: 2026-07-21
Released by: ggrossetie
Published by: GitHub</p>
<p>Logs: <a href="https://github.com/asciidoctor/asciidoctor.js/compare/v4.0.4...v4.0.5">full diff</a></p>
<h2>Changelog</h2>
<h3>Bug Fixes</h3>
<ul>
<li>Fix <code>Document#getLogger()</code> (and <code>getLogger()</code> on any prototype augmented by <code>applyLogging()</code>: <code>Converter</code>, <code>Parser</code>, <code>PathResolver</code>, <code>Table.ParserContext</code>) silently ignoring a per-instance override of the <code>logger</code> getter, even though its own JSDoc describes it as "a method alias for the <code>logger</code> getter". <code>applyLogging()</code> (<code>logging.js</code>) installed <code>getLogger</code> as a fixed arrow function with no <code>this</code> binding, so it always fell back to the global <code>LoggerManager.logger</code> instead of resolving through <code>this.logger</code> — breaking the <code>logger</code> option to <code>convert()</code>/<code>load()</code> once the async-local-storage scope from <code>load()</code> had closed (i.e. during <code>doc.convert()</code>, when most block/inline converters and extensions run). Extensions/converters that follow the document
ed <code>doc.getLogger()</code> pattern (e.g. to log a warning with <code>messageWithContext()</code>) would have those messages silently escape a caller-supplied logger such as a <code>MemoryLogger</code></li>
<li>Fix inline macro extensions ignoring the <code>contentModel</code>/<code>positionalAttrs</code> (or the DSL <code>contentModel()</code>/<code>positionalAttributes()</code>/<code>resolveAttributes()</code> setters) configuration, so the macro’s bracket content was never parsed into named/positional attributes and always ended up as a raw string in <code>attributes.text</code> instead — e.g. <code>registry.inlineMacro(function () { this.named('emoji'); this.positionalAttributes('size'); this.process(...) })</code> produced <code>{ text: '2x' }</code> instead of <code>{ '1': '2x', size: '2x' }</code> for <code>emoji:smile[2x]</code>. <code>Substitutors#subMacros</code> (the inline macro substitution path in <code>substitutors.js</code>) read the extension config with keys that were never populated by the DSL/static config (<a href="https://redirect.github.com/asciidoctor/asciidoctor.js/issues/1857">asciidoctor/asciidoctor.js#1857</a>)</li>
</ul>
<h3>Improvements</h3>
<ul>
<li>Extension <code>Processor</code> config keys (<code>contentModel</code>, <code>positionalAttrs</code>, <code>defaultAttrs</code>) now use <code>camelCase</code> consistently across every registration style — the DSL setters, class-based <code>static config</code>, and the block/inline macro substitution code that reads them. The legacy Ruby-style <code>snake_case</code> keys (<code>content_model</code>, <code>positional_attrs</code>, <code>pos_attrs</code>, <code>default_attrs</code>) are still accepted for backward compatibility when a processor class declares its config directly (<code>static config = { content_model: 'attributes' }</code> or <code>MyProcessor.config = { content_model: 'attributes' }</code>). <code>Processor.config</code> also gained a static setter, so assigning a static config object after the class declaration (as shown in the <code>BlockMacroProcessor</code>/<code>InlineMacroProcessor</code> JSDoc examples) no longer throws a <code>TypeError</code></li
>
<li>Type <code>AbstractNode#logger</code>/<code>#getLogger()</code> and <code>Reader</code>/<code>PreprocessorReader#logger</code>/<code>#getLogger()</code>/<code>#createLogMessage()</code> with the new <code>LoggerLike</code> union (<code>Logger | MemoryLogger | NullLogger | Console</code>, exported from <code>logging.js</code>) instead of a bare <code>object</code>. In <code>reader.js</code>, fields and helper methods that are only ever touched within the class that declares them (<code>Reader’s cursor mark, </code>PreprocessorReader’s include/conditional-directive bookkeeping) are now real JS <code>#private</code> members instead of <code>_</code>-prefixed by convention; the remaining <code>_</code>-prefixed fields that <code>PreprocessorReader</code> must read/reassign (<code>_dir</code>, <code>_document</code>, <code>_lines</code>, …) are annotated <code>@internal</code> so they’re stripped from the generated public <code>.d.ts</code> without changing runtime access</
li>
</ul>
<h2>v4.0.4</h2>
<h2>Summary</h2>
<h2>Release meta</h2>
<p>Released on: 2026-07-15
Released by: ggrossetie
Published by: GitHub</p>
<p>Logs: <a href="https://github.com/asciidoctor/asciidoctor.js/compare/v4.0.3...v4.0.4">full diff</a></p>
<h2>Changelog</h2>
<h3>Improvements</h3>
<ul>
<li>Declare the instance form ("style 3") of the <code>Registry</code> extension registration methods in the TypeScript typings. The runtime has always accepted an already-constructed processor (<code>registry.includeProcessor(new MyIncludeProcessor())</code>) 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. <code>preprocessor</code>, <code>treeProcessor</code>, <code>postprocessor</code>, <code>includeProcessor</code>, <code>docinfoProcessor</code>, <code>block</code>, <code>blockMacro</code> and <code>inlineMacro</code> 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</li>
<li>Type the filter callback accepted by <code>AbstractBlock#findBy</code> (and its <code>query</code> alias) as <code>(node: AbstractBlock) => boolean | string</code> instead of the bare <code>Function</code>, so the candidate node passed to the callback resolves as an <code>AbstractBlock</code> without casts — both in the two-argument form and in the <code>findBy(callback)</code> shorthand</li>
<li>Type the reader received by preprocessor and include processor callbacks as <code>PreprocessorReader</code> instead of <code>Reader</code>, and export <code>PreprocessorReader</code> from the package root. <code>Preprocessor#process</code>, <code>IncludeProcessor#process</code> and the matching DSL <code>process(fn)</code> callbacks actually receive a <code>PreprocessorReader</code> at runtime, so its members (<code>pushInclude</code>, <code>getIncludeDepth</code>, …) now resolve without casts or manual module augmentation</li>
</ul>
<h3>Infrastructure</h3>
<ul>
<li>Display the package version number in the generated TypeDoc API documentation (<code>includeVersion</code> option), so both the <code>@asciidoctor/core</code> API docs and the <code>asciidoctor</code> CLI docs show which release they document (e.g. <code>@asciidoctor/core - v4.0.3</code>)</li>
<li>Publish a <code>major.minor</code> alias of the TypeDoc API documentation on each stable release — e.g. releasing v4.0.4 (re)deploys the docs to both <code>4.0.4/</code> and <code>4.0/</code> on GitHub Pages, so the <code>4.0</code> URL always points to the documentation of the latest 4.0.x release</li>
<li>Simplify the release workflow: the intermediate "Bump version for release" workflow (<code>release-bump.yml</code>) 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 <code>main</code> or from a maintenance branch (e.g. <code>4.0.x</code> or <code>v4.0.x</code>). The git commands (commit, tag, push) live in the workflow itself; the release scripts are reduced to three focused tools: <code>tasks/version.js <version></code> (sets both package versions and keeps the <code>asciidoctor</code> → <code>@asciidoctor/core</code> dependency in sync), <code>tasks/changelog.js release <version></code> (rolls the Unreleased section into a dated release section) / <code>tasks/changelog.js notes <version></code> (prints the Markdown release notes of a version to stdout), and <code>tasks/publish.js</code> (publishes both p
ackages to npmjs). <code>tasks/release.js</code>, <code>scripts/publish.sh</code>, the <code>npm run release</code> script and the <code>skip_publish</code> 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 <code>ref</code> input so the release builds the tagged commit (with the bumped version) rather than the pre-bump branch head</li>
<li>Publishing a maintenance release no longer steals the npm <code>latest</code> dist-tag: when the version being published is older than the currently published <code>latest</code> (e.g. releasing 4.0.5 while 4.1.0 is out), the packages are published under a <code>latest-<major>.<minor></code> dist-tag (e.g. <code>latest-4.0</code>, following the <code>latest-2</code> convention already used for the 2.x line) instead</li>
</ul>
<h2>v4.0.3</h2>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/asciidoctor/asciidoctor.js/blob/main/CHANGELOG.adoc">@asciidoctor/core's changelog</a>.</em></p>
<blockquote>
<p>== v4.0.5 (2026-07-21)</p>
<p>Bug Fixes::</p>
<ul>
<li>Fix <code>Document#getLogger()</code> (and <code>getLogger()</code> on any prototype augmented by <code>applyLogging()</code>: <code>Converter</code>, <code>Parser</code>, <code>PathResolver</code>, <code>Table.ParserContext</code>) silently ignoring a per-instance override of the <code>logger</code> getter, even though its own JSDoc describes it as "a method alias for the <code>logger</code> getter". <code>applyLogging()</code> (<code>logging.js</code>) installed <code>getLogger</code> as a fixed arrow function with no <code>this</code> binding, so it always fell back to the global <code>LoggerManager.logger</code> instead of resolving through <code>this.logger</code> — breaking the <code>logger</code> option to <code>convert()</code>/<code>load()</code> once the async-local-storage scope from <code>load()</code> had closed (i.e. during <code>doc.convert()</code>, when most block/inline converters and extensions run). Extensions/converters that follow the document
ed <code>doc.getLogger()</code> pattern (e.g. to log a warning with <code>messageWithContext()</code>) would have those messages silently escape a caller-supplied logger such as a <code>MemoryLogger</code></li>
<li>Fix inline macro extensions ignoring the <code>contentModel</code>/<code>positionalAttrs</code> (or the DSL <code>contentModel()</code>/<code>positionalAttributes()</code>/<code>resolveAttributes()</code> setters) configuration, so the macro's bracket content was never parsed into named/positional attributes and always ended up as a raw string in <code>attributes.text</code> instead — e.g. <code>registry.inlineMacro(function () { this.named('emoji'); this.positionalAttributes('size'); this.process(...) })</code> produced <code>{ text: '2x' }</code> instead of <code>{ '1': '2x', size: '2x' }</code> for <code>emoji:smile[2x]</code>. <code>Substitutors#subMacros</code> (the inline macro substitution path in <code>substitutors.js</code>) read the extension config with keys that were never populated by the DSL/static config ({uri-repo}/issues/1857<a href="https://redirect.github.com/asciidoctor/asciidoctor.js/issues/1857">#1857</a>)</li>
</ul>
<p>Improvements::</p>
<ul>
<li>Extension <code>Processor</code> config keys (<code>contentModel</code>, <code>positionalAttrs</code>, <code>defaultAttrs</code>) now use <code>camelCase</code> consistently across every registration style — the DSL setters, class-based <code>static config</code>, and the block/inline macro substitution code that reads them. The legacy Ruby-style <code>snake_case</code> keys (<code>content_model</code>, <code>positional_attrs</code>, <code>pos_attrs</code>, <code>default_attrs</code>) are still accepted for backward compatibility when a processor class declares its config directly (<code>static config = { content_model: 'attributes' }</code> or <code>MyProcessor.config = { content_model: 'attributes' }</code>). <code>Processor.config</code> also gained a static setter, so assigning a static config object after the class declaration (as shown in the <code>BlockMacroProcessor</code>/<code>InlineMacroProcessor</code> JSDoc examples) no longer throws a <code>TypeError</code></li
>
<li>Type <code>AbstractNode#logger</code>/<code>#getLogger()</code> and <code>Reader</code>/<code>PreprocessorReader#logger</code>/<code>#getLogger()</code>/<code>#createLogMessage()</code> with the new <code>LoggerLike</code> union (<code>Logger | MemoryLogger | NullLogger | Console</code>, exported from <code>logging.js</code>) instead of a bare <code>object</code>. In <code>reader.js</code>, fields and helper methods that are only ever touched within the class that declares them (<code>Reader</code>'s cursor mark, <code>PreprocessorReader</code>'s include/conditional-directive bookkeeping) are now real JS <code>#private</code> members instead of <code>_</code>-prefixed by convention; the remaining <code>_</code>-prefixed fields that <code>PreprocessorReader</code> must read/reassign (<code>_dir</code>, <code>_document</code>, <code>_lines</code>, …) are annotated <code>@internal</code> so they're stripped from the generated public <code>.d.ts</code> without changing runtime a
ccess</li>
</ul>
<p>== v4.0.4 (2026-07-15)</p>
<p>Improvements::</p>
<ul>
<li>Declare the instance form ("style 3") of the <code>Registry</code> extension registration methods in the TypeScript typings. The runtime has always accepted an already-constructed processor (<code>registry.includeProcessor(new MyIncludeProcessor())</code>) 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. <code>preprocessor</code>, <code>treeProcessor</code>, <code>postprocessor</code>, <code>includeProcessor</code>, <code>docinfoProcessor</code>, <code>block</code>, <code>blockMacro</code> and <code>inlineMacro</code> 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</li>
<li>Type the filter callback accepted by <code>AbstractBlock#findBy</code> (and its <code>query</code> alias) as <code>(node: AbstractBlock) => boolean | string</code> instead of the bare <code>Function</code>, so the candidate node passed to the callback resolves as an <code>AbstractBlock</code> without casts — both in the two-argument form and in the <code>findBy(callback)</code> shorthand</li>
<li>Type the reader received by preprocessor and include processor callbacks as <code>PreprocessorReader</code> instead of <code>Reader</code>, and export <code>PreprocessorReader</code> from the package root. <code>Preprocessor#process</code>, <code>IncludeProcessor#process</code> and the matching DSL <code>process(fn)</code> callbacks actually receive a <code>PreprocessorReader</code> at runtime, so its members (<code>pushInclude</code>, <code>getIncludeDepth</code>, …) now resolve without casts or manual module augmentation</li>
</ul>
<p>Infrastructure::</p>
<ul>
<li>Display the package version number in the generated TypeDoc API documentation (<code>includeVersion</code> option), so both the <code>@asciidoctor/core</code> API docs and the <code>asciidoctor</code> CLI docs show which release they document (e.g. <code>@asciidoctor/core - v4.0.3</code>)</li>
<li>Publish a <code>major.minor</code> alias of the TypeDoc API documentation on each stable release — e.g. releasing v4.0.4 (re)deploys the docs to both <code>4.0.4/</code> and <code>4.0/</code> on GitHub Pages, so the <code>4.0</code> URL always points to the documentation of the latest 4.0.x release</li>
<li>Simplify the release workflow: the intermediate "Bump version for release" workflow (<code>release-bump.yml</code>) 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 <code>main</code> or from a maintenance branch (e.g. <code>4.0.x</code> or <code>v4.0.x</code>). The git commands (commit, tag, push) live in the workflow itself; the release scripts are reduced to three focused tools: <code>tasks/version.js <version></code> (sets both package versions and keeps the <code>asciidoctor</code> → <code>@asciidoctor/core</code> dependency in sync), <code>tasks/changelog.js release <version></code> (rolls the Unreleased section into a dated release section) / <code>tasks/changelog.js notes <version></code> (prints the Markdown release notes of a version to stdout), and <code>tasks/publish.js</code> (publishes both p
ackages to npmjs). <code>tasks/release.js</code>, <code>scripts/publish.sh</code>, the <code>npm run release</code> script and the <code>skip_publish</code> 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 <code>ref</code> input so the release builds the tagged commit (with the bumped version) rather than the pre-bump branch head</li>
<li>Publishing a maintenance release no longer steals the npm <code>latest</code> dist-tag: when the version being published is older than the currently published <code>latest</code> (e.g. releasing 4.0.5 while 4.1.0 is out), the packages are published under a <code>latest-<major>.<minor></code> dist-tag (e.g. <code>latest-4.0</code>, following the <code>latest-2</code> convention already used for the 2.x line) instead</li>
</ul>
<p>== v4.0.3 (2026-07-13)</p>
<p>Bug Fixes::</p>
<ul>
<li>Fix AsciiDoc table cells (<code>a</code>) losing their content when they belong to a table that is itself nested inside another AsciiDoc cell — the deeper cells rendered as an empty <code><div class="content"></div></code> (text became invisible). <code>Document#convert</code> computes each AsciiDoc cell's inner content in <code>_convertAsciiDocCells</code>, but that pass only ran on the root document (guarded by <code>!parentDocument</code>) and, when it converted an AsciiDoc cell's inner document, never recursed into the tables <em>inside</em> that inner document. So a nested table's own AsciiDoc cells were rendered before their <code>_innerContent</code> was ever set. The pass now recurses into a cell's inner document before rendering it, so AsciiDoc cells at any nesting depth have their content computed first</li>
</ul>
<p>== v4.0.2 (2026-07-06)</p>
<p>Improvements::</p>
<ul>
<li>Improve the TypeScript typings of the extension registration DSL so that the callback (block) form of every <code>Registry</code> processor method is fully typed. <code>block</code>, <code>blockMacro</code>, <code>inlineMacro</code>, <code>preprocessor</code>, <code>treeProcessor</code>, <code>postprocessor</code>, <code>includeProcessor</code> and <code>docinfoProcessor</code> now expose distinct overloads for the class form and the registration-function form; the function's <code>this</code> is inferred as the matching DSL interface (e.g. <code>BlockProcessorDslInterface</code>, <code>PreprocessorDslInterface</code>), and each <code>process(fn)</code> callback receives typed arguments and return type appropriate to its processor — e.g. block/inline macros get <code>(parent: AbstractBlock, target: string, attributes)</code>, the preprocessor gets <code>(document: Document, reader: Reader)</code>, the postprocessor <code>(document, output: string) => string</code>. The re
levant <code>createBlock</code> / <code>createInline</code> helpers are surfaced on <code>this</code>, so <code>block('shout', function () { this.process((parent, reader) => this.createBlock(parent, 'paragraph', reader.getLines().join('\n'))) })</code> type-checks without casts. New DSL interface types (<code>PreprocessorDslInterface</code>, <code>TreeProcessorDslInterface</code>, <code>PostprocessorDslInterface</code>, <code>BlockMacroProcessorDslInterface</code>) are exported, and a compile-only type test (<code>npm run test:types</code>) guards the typings against regressions. <code>IncludeProcessor#handles</code> accepts both the Ruby-style arity-1 override (<code>handles(target)</code>) and the arity-2 override (<code>handles(doc, target)</code>) — its first parameter is typed <code>Document | string</code> so either shape type-checks when subclassing</li>
<li>The HTML5 converter can now inline an SVG image whose target is a <code>data:</code> URI (e.g. <code>image::data:image/svg+xml;base64,…[opts=inline]</code>). <code>readSvgContents</code> decodes both Base64 and percent-encoded <code>data:</code> payloads instead of only reading from a file or remote URI, so a diagram or image embedded as a data-URI can be rendered as inline <code><svg></code> without writing a file or enabling <code>allow-uri-read</code>. The SVG format is inferred from the <code>image/svg+xml</code> media type, so an explicit <code>format=svg</code> attribute is no longer required on a <code>data:</code> URI target</li>
</ul>
<p>Bug Fixes::</p>
<ul>
<li><code>imageUri</code> now returns a <code>data:</code> URI image target as-is instead of attempting to read it as a file or fetch it via the Fetch API; previously, with both <code>data-uri</code> and <code>allow-uri-read</code> set, a <code>data:</code> URI target (e.g. <code>data:image/png;base64,…</code>) triggered a spurious "could not retrieve image data from URI" warning</li>
<li>Fix the built-in <code>asciidoctor-version</code> attribute reporting the hard-coded upstream Ruby version (<code>3.0.0.dev</code>) instead of the actual library version — it now resolves to the <code>@asciidoctor/core</code> package version (e.g. <code>4.0.1</code>), so references such as <code>{asciidoctor-version}</code> reflect the real release</li>
<li>Report <code>Asciidoctor.js</code> (instead of <code>Asciidoctor</code>) in the HTML5 <code><meta name="generator"></code> and manpage <code>Generator:</code> metadata, so the generated output identifies the JavaScript library and its version (e.g. <code>Asciidoctor.js 4.0.1</code>)</li>
<li>Fix natural cross-references (e.g. <code>+<<Some section title>>+</code>) not resolving inside list items, description list items and table cells — they rendered as <code><a href="#Some section title">[Some section title]</a></code> instead of linking to the section's generated ID. Unlike paragraph text (substituted lazily during conversion, after the reftext→id map is built), list/cell/dlist text is pre-computed eagerly in <code>_resolveAllTexts</code>, which ran <em>before</em> the map existed; the synchronous <code>resolveId</code> fallback then matched against the raw <code>reftext</code> attribute rather than the computed <code>xreftext</code> (a section's title), so the lookup failed. Text pre-computation now runs in two passes — titles and reftexts first, then the reftext→id map is built, then list/cell/dlist content text — restoring Ruby's invariant that all references are known before any content substitution resolves a natu
ral cross-reference</li>
<li>Fix a registered converter's flat string trait properties (convention <a href="https://redirect.github.com/asciidoctor/asciidoctor.js/issues/2">#2</a>, e.g. <code>converter.outfilesuffix = '.html'</code>) being silently overwritten with accessor functions after the first conversion — normalizing the converter applied the <code>BackendTraits</code> mixin, which installed same-named accessor <em>methods</em> on the instance, clobbering the author's strings. Code reading <code>converter.outfilesuffix</code> then got a function instead of <code>'.html'</code> (and only after normalization, so the value's type changed mid-lifecycle). <code>applyBackendTraits</code> no longer overwrites an existing same-named data property, and <code>Document</code> reads backend traits through <code>_getBackendTraits()</code> rather than the accessor methods, so flat string properties stay strings throughout</li>
<li>Fix JavaScript templates not being applied depending on their file extension and the project's module format ({uri-repo}/issues/1841<a href="https://redirect.github.com/asciidoctor/asciidoctor.js/issues/1841">#1841</a>) — a <code>.js</code> template in a <code>"type": "module"</code> (ESM) project crashed with <code>template.render is not a function</code>, and <code>.mjs</code> templates were silently ignored (the extension was not even recognised). The template loader used a CommonJS <code>require()</code> for <code>.js</code>/<code>.cjs</code> files, which returned the ESM namespace object (not the render function) for ESM <code>.js</code> files and did not handle <code>.mjs</code> at all. <code>.js</code> and <code>.mjs</code> templates are now loaded with a dynamic <code>import()</code> (which Node resolves as either ESM or CommonJS) and the render function is taken from the module's default export, so all combinations of extension (<code>.js</code>,
<code>.cjs</code>, <code>.mjs</code>) and module format (ESM or CommonJS) work. The same loading is applied to the optional <code>helpers</code> file (<code>helpers.js</code>/<code>helpers.cjs</code>/<code>helpers.mjs</code>), which can now also be an ES module</li>
</ul>
<p>Infrastructure::</p>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="https://github.com/asciidoctor/asciidoctor.js/commit/28ab8b28ecee3978e20329d722a7846690f7bbf2"><code>28ab8b2</code></a> 4.0.5</li>
<li><a href="https://github.com/asciidoctor/asciidoctor.js/commit/ce1b7326b4ad4c1ba4f688c0319b69591e1e93c3"><code>ce1b732</code></a> refactor(core): use real #private fields in reader.js, type logger APIs with ...</li>
<li><a href="https://github.com/asciidoctor/asciidoctor.js/commit/29af7d6f45509edfd21d2f9e1111b0d2e3012d65"><code>29af7d6</code></a> fix(logging): make Document#getLogger() honor per-instance logger override</li>
<li><a href="https://github.com/asciidoctor/asciidoctor.js/commit/37eb46d3dc1b7af32d27bb9eaea6a0f0076c69e7"><code>37eb46d</code></a> test(extensions): cover legacy config aliases and every macro/block registrat...</li>
<li><a href="https://github.com/asciidoctor/asciidoctor.js/commit/71f113adb33e53a07bd50382f236659525f367e1"><code>71f113a</code></a> fix(extensions): parse inline macro content into attributes per contentModel ...</li>
<li><a href="https://github.com/asciidoctor/asciidoctor.js/commit/a33f87e72c8e8633aa023ecf9f088bcac1b6c9a6"><code>a33f87e</code></a> 4.0.4</li>
<li><a href="https://github.com/asciidoctor/asciidoctor.js/commit/4bc7b65dbd1a43b7cd07af17bd431a5cafa8642d"><code>4bc7b65</code></a> ci(release): dispatch the release workflow with a version and simplify the re...</li>
<li><a href="https://github.com/asciidoctor/asciidoctor.js/commit/8686e8ec3bee277da74d80fa8f69200d64032b35"><code>8686e8e</code></a> fix(types): type the findBy/query filter callback and selector object</li>
<li><a href="https://github.com/asciidoctor/asciidoctor.js/commit/f376d772d96a118683eee8ce581b505cf394b283"><code>f376d77</code></a> fix(types): declare the processor instance form and PreprocessorReader in the...</li>
<li><a href="https://github.com/asciidoctor/asciidoctor.js/commit/7e03222708427236917a9947dcc25ad15cf3557d"><code>7e03222</code></a> docs(migration): document the CLI --require/--extension split</li>
<li>Additional commits viewable in <a href="https://github.com/asciidoctor/asciidoctor.js/compare/v4.0.0...v4.0.5">compare view</a></li>
</ul>
</details>
<br />
Updates `js-yaml` from 5.2.0 to 5.2.1
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/nodeca/js-yaml/blob/master/CHANGELOG.md">js-yaml's changelog</a>.</em></p>
<blockquote>
<h2>[5.2.1] - 2026-07-02</h2>
<h3>Fixed</h3>
<ul>
<li>Add <code>Map</code> support to !!omap (should work when <code>realMapTag</code> used)</li>
</ul>
<h3>Security</h3>
<ul>
<li>Remove quadratic complexity from !!omap <code>addItem</code>. Regression from v5
(usually not critical, because YAML11_SCHEMA is not default anymore).</li>
</ul>
<h2>4.3.0, 3.15.0 - 2026-06-27</h2>
<h3>Security</h3>
<ul>
<li>Backported <code>maxTotalMergeKeys</code> option.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="https://github.com/nodeca/js-yaml/commit/ac16b42c46c11c5c7f66062bfc78b168b5f07ecd"><code>ac16b42</code></a> 5.2.1 released</li>
<li><a href="https://github.com/nodeca/js-yaml/commit/4a864e55eec5044da67ca95a13f48c73e9ae8c0d"><code>4a864e5</code></a> Deps bump</li>
<li><a href="https://github.com/nodeca/js-yaml/commit/39f3211a2f01b3c6982710cf21434ab7060acefe"><code>39f3211</code></a> !!omap: add <code>Map</code> support and remove quadratic complexity</li>
<li><a href="https://github.com/nodeca/js-yaml/commit/ff17f1e5bbd1d0dcfb9567ff4526f7206a666f7b"><code>ff17f1e</code></a> Changelog update</li>
<li><a href="https://github.com/nodeca/js-yaml/commit/8ed15f1cf6a0f1818ea4c0cd5d3973e87af2158f"><code>8ed15f1</code></a> deps bump</li>
<li><a href="https://github.com/nodeca/js-yaml/commit/1a562dc14cac81354643e45936cde968b6da324c"><code>1a562dc</code></a> Fix changelog link</li>
<li>See full diff in <a href="https://github.com/nodeca/js-yaml/compare/5.2.0...5.2.1">compare view</a></li>
</ul>
</details>
<br />
Updates `sass` from 1.101.0 to 1.101.3
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/sass/dart-sass/releases">sass's releases</a>.</em></p>
<blockquote>
<h2>Dart Sass 1.101.3</h2>
<p>To install Sass 1.101.3, download one of the packages below and <a href="https://katiek2.github.io/path-doc/">add it to your PATH</a>, or see <a href="https://sass-lang.com/install">the Sass website</a> for full installation instructions.</p>
<h1>Changes</h1>
<ul>
<li>No user-visible changes.</li>
</ul>
<p>See the <a href="https://github.com/sass/dart-sass/blob/master/CHANGELOG.md#11013">full changelog</a> for changes in earlier releases.</p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/sass/dart-sass/blob/main/CHANGELOG.md">sass's changelog</a>.</em></p>
<blockquote>
<h2>1.101.3</h2>
<ul>
<li>No user-visible changes.</li>
</ul>
<h2>1.101.2</h2>
<ul>
<li>Fix a bug where the deprecation warning for vendor-prefixed <code>expression()</code>
functions would incorrectly indicate whether or not the function would be
invalid Sass in Dart Sass 2.0.0.</li>
</ul>
<h2>1.101.1</h2>
<ul>
<li>Sass stack trace entries are now always either absolute URLs, absolute paths,
or paths relative to the current working directory. Previously, if a
stylesheet was loaded using a relative URL (as from a load path), that
relative URL was listed even if it couldn't be resolved relative to the
current working directory. However, this created potential ambiguities, so
this behavior has been removed.</li>
</ul>
<h3>Command Line Interface</h3>
<ul>
<li><code>--watch</code> mode now handles atomically-written files more gracefully.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="https://github.com/sass/dart-sass/commit/e8c12331ea5304a1d641d6a6bd4cb526cb3800b9"><code>e8c1233</code></a> Fix some GitHub actions issues introduced by the Zizmor refactor (<a href="https://redirect.github.com/sass/dart-sass/issues/2798">#2798</a>)</li>
<li><a href="https://github.com/sass/dart-sass/commit/d676118ace4b6b196383f26cf5ffda4f9c61b239"><code>d676118</code></a> Merge pull request <a href="https://redirect.github.com/sass/dart-sass/issues/2797">#2797</a> from sass/lints</li>
<li><a href="https://github.com/sass/dart-sass/commit/548e6604c5eed5137b148a839513c7444582eb3c"><code>548e660</code></a> Prefer interpolation to compose strings</li>
<li><a href="https://github.com/sass/dart-sass/commit/b443ffe759f7235170b1fd6e540dcb8e459f3dca"><code>b443ffe</code></a> Use function type syntax</li>
<li><a href="https://github.com/sass/dart-sass/commit/3d28f6a83ff8c16e7b1980f6a4e46d62f1505fce"><code>3d28f6a</code></a> Add <code>@override</code></li>
<li><a href="https://github.com/sass/dart-sass/commit/e182ba21e1459c5efad0247e9bc5ba212a870db3"><code>e182ba2</code></a> Expand dependency constraints (<a href="https://redirect.github.com/sass/dart-sass/issues/2796">#2796</a>)</li>
<li><a href="https://github.com/sass/dart-sass/commit/66f9d41f79231eebb4380a126bbc662c13f2d7d0"><code>66f9d41</code></a> Bump analyzer from 10.2.0 to 13.3.0 (<a href="https://redirect.github.com/sass/dart-sass/issues/2795">#2795</a>)</li>
<li><a href="https://github.com/sass/dart-sass/commit/ab4026df5efe9eef1d7accc2653bdf050c3c1c14"><code>ab4026d</code></a> Use the latest lints package (<a href="https://redirect.github.com/sass/dart-sass/issues/2789">#2789</a>)</li>
<li><a href="https://github.com/sass/dart-sass/commit/fbb1fe0533cc78c14b848c709b30d599c5bf86e1"><code>fbb1fe0</code></a> Bump zizmorcore/zizmor-action from 0.5.6 to 0.5.7 (<a href="https://redirect.github.com/sass/dart-sass/issues/2793">#2793</a>)</li>
<li><a href="https://github.com/sass/dart-sass/commit/8abfa4d23d447bcada1efe415066458a08a0a155"><code>8abfa4d</code></a> Fix <code>--watch</code> not recompiling files modified via atomic save (<a href="https://redirect.github.com/sass/dart-sass/issues/2791">#2791</a>)</li>
<li>Additional commits viewable in <a href="https://github.com/sass/dart-sass/compare/1.101.0...1.101.3">compare view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [PR] Bump the all-dependencies group across 1 directory with 3 updates [netbeans-antora-ui]
Posted by "ebarboni (via GitHub)" <gi...@apache.org>.
ebarboni merged PR #133:
URL: https://github.com/apache/netbeans-antora-ui/pull/133
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists