AdocWeave vscode 0.48.2

主な変更

• 日本語に隣接するinline書式のhighlightが正しく閉じるようになりました。 これまで「include::の扱い」のように、閉じ側のマーカーの直後に日本語が続くと、monospaceの色が行末まで続いていました。bold（*）とitalic（_）も同じ症状でした。閉じ側の直後にスペースを入れる必要はなくなります。

原因は、書式マーカーの前後判定に使っていた\wが、VS Codeの正規表現エンジンではUnicodeの語文字として動き、日本語の文字にも一致していたことです。AdocWeave本体の解析器は、CJK文字を語の境界とみなす判断をしており（文字の形で語を分けるため）、文法定義だけがそれに追随していませんでした。判定をASCIIの英数字とアンダースコアに限定し、本体と同じ範囲で色付けします。

英語の既存の挙動は変わりません。語の内側にあるマーカー（snake_caseの_など）は引き続き書式になりません。

対応環境

Visual Studio Code 1.107.0以降が必要です。

自動取得はlinuxのx86-64とARM64、macOSのARM64、Windowsのx86-64に対応します。これら以外では自動取得へ進まず、対応環境を示して起動に失敗します。手動で導入した実行ファイルの指定は、この制限を受けません。

未信頼ワークスペースでは拡張を起動しないため、自動取得も行いません。

対応関係

拡張とLanguage Serverの製品バージョンを一致させる必要はありません。利用できる機能は、接続時に交換する標準LSP capabilityから決まります。自動取得では、公開済みのadocweave-lspのうち最新の安定版を選びます。

• 製品バージョン：0.48.2

v0.48.2への移行

• 利用者の作業は不要です。拡張画面から更新してください。
• 閉じ側のマーカーの直後にスペースを入れて回避していた場合、そのスペースは不要になります。残しておいても表示は変わりません。

更新とロールバック

Visual Studio MarketplaceまたはOpen VSX Registryから導入した場合は、editorの拡張画面から更新および以前の版への切り替えができます。VSIXを手動で導入した場合は、新しいVSIXをcode --install-extension <file> --forceで導入し、Windowを再読込します。

自動取得したLanguage Serverは、拡張のglobal storageにあるservers内のadocweave-lsp-<version>-<target>形式のディレクトリへ置きます。同じ版を取得済みの場合は再取得せず、新しい版を取得したときは以前の版を削除します。

既知の制約

• highlightの語境界の判定はASCIIに限定しています。éやキリル文字などASCII以外のラテン系文字に隣接するマーカーは、本体の解析器では書式にならない場合でもhighlightは付きます。日本語文書には影響しません。
• 自動取得したLanguage Serverの版を拡張の設定から固定できません。常に最新の安定版を取得します。
• 自動取得ではattestationを検証しません。checksumは照合します。
• Marketplaceの索引更新には遅れがあり、公開直後は拡張画面へ現れないことがあります。

配布物の検証

対象Releaseのsha256.sumでarchiveを検査し、gh attestation verify <asset> --repo KeishiS/adocweaveでattestationを検証してください。

AdocWeave vscode 0.48.1

主な変更

• 0.48.0で自動取得が働かなかった問題を直しました。 adocweave-lspを導入していない環境で、拡張が取得へ進まずlanguage-server-not-foundで停止していました。取得先を決める条件が実際の環境で偽になり、自動取得が黙って無効になっていたためです。条件を外し、取得先は常に拡張のglobal storageとします。
• 選択の経過を出力パネルへ記録します。 設定にもPATHにも見つからず取得へ進んだこと、および取得先をAdocWeaveの出力に残します。起動しなかったときに、設定、PATH、自動取得のどこで止まったのかを切り分けられます。

この版から、自動取得は実際の環境で検証します。設定とPATHのどちらにもLanguage Serverがない状態でVisual Studio Codeを起動し、公開済みのGitHub Releaseから取得して診断が返るまでを、公開前の検査に含めます。0.48.0では取得経路を差し替えた単体試験しかなく、実際のnetworkとfilesystemを通る経路が検証されていませんでした。

対応環境

Visual Studio Code 1.107.0以降が必要です。

自動取得はlinuxのx86-64とARM64、macOSのARM64、Windowsのx86-64に対応します。これら以外では自動取得へ進まず、対応環境を示して起動に失敗します。手動で導入した実行ファイルの指定は、この制限を受けません。

未信頼ワークスペースでは拡張を起動しないため、自動取得も行いません。

対応関係

拡張とLanguage Serverの製品バージョンを一致させる必要はありません。利用できる機能は、接続時に交換する標準LSP capabilityから決まります。自動取得では、公開済みのadocweave-lspのうち最新の安定版を選びます。

• 製品バージョン：0.48.1

v0.48.1への移行

• 利用者の作業は不要です。拡張画面から更新してください。
• 0.48.0で自動取得が働かなかった場合は、この版で解決します。解決しない場合は、出力パネルのAdocWeaveに記録された行を添えて報告してください。どの段で止まったのかが分かります。

更新とロールバック

Visual Studio MarketplaceまたはOpen VSX Registryから導入した場合は、editorの拡張画面から更新および以前の版への切り替えができます。VSIXを手動で導入した場合は、新しいVSIXをcode --install-extension <file> --forceで導入し、Windowを再読込します。

自動取得したLanguage Serverは、拡張のglobal storageにあるservers内のadocweave-lsp-<version>-<target>形式のディレクトリへ置きます。同じ版を取得済みの場合は再取得せず、新しい版を取得したときは以前の版を削除します。

既知の制約

• 自動取得したLanguage Serverの版を拡張の設定から固定できません。常に最新の安定版を取得します。
• 自動取得ではattestationを検証しません。checksumは照合します。
• Marketplaceの索引更新には遅れがあり、公開直後は拡張画面へ現れないことがあります。

配布物の検証

対象Releaseのsha256.sumでarchiveを検査し、gh attestation verify <asset> --repo KeishiS/adocweaveでattestationを検証してください。

AdocWeave vscode 0.48.0

主な変更

• Language Serverを自動で取得します。 これまでは拡張を導入しても、別途adocweave-lspを導入してPATHまたは設定へ登録するまで文書解析が動きませんでした。どちらにも見つからない場合、拡張がGitHub Releaseから最新のLanguage Serverを取得して起動します。
• 探索順はadocweave.server.pathの絶対path、PATH、自動取得の三段です。 導入済みの実行ファイルがあれば常にそちらが選ばれ、自動取得は行われません。
• 取得したarchiveはchecksumを照合してから展開します。 同じReleaseのsha256.sumに記載された値と突き合わせ、一致しない場合は展開せず、理由を示して起動を中止します。

attestationの検証は行いません。sigstoreの検証処理を拡張へ組み込む必要があり、checksumの照合に比べて費用が大きいためです。より強い保証が必要な場合は、利用者向けの配布物導入手順、Nixまたはpackage registryから導入し、その実行ファイルをadocweave.server.pathまたはPATHで指定してください。

対応環境

Visual Studio Code 1.107.0以降が必要です。

自動取得はlinuxのx86-64とARM64、macOSのARM64、Windowsのx86-64に対応します。Intel macOSとWindows ARM64向けのarchiveは配布していないため、これらの環境では自動取得へ進まず、対応環境を示して起動に失敗します。手動で導入した実行ファイルの指定は、この制限を受けません。

未信頼ワークスペースでは拡張を起動しないため、自動取得も行いません。

対応関係

拡張とLanguage Serverの製品バージョンを一致させる必要はありません。利用できる機能は、接続時に交換する標準LSP capabilityから決まります。自動取得では、公開済みのadocweave-lspのうち最新の安定版を選びます。

• 製品バージョン：0.48.0

v0.48.0への移行

• 利用者の作業は不要です。すでにadocweave-lspを導入している場合、その実行ファイルが引き続き優先されます。
• 自動取得を使いたくない場合は、adocweave-lspを導入してadocweave.server.pathまたはPATHで指定してください。拡張側に自動取得を止める設定は設けていません。

更新とロールバック

Visual Studio MarketplaceまたはOpen VSX Registryから導入した場合は、editorの拡張画面から更新および以前の版への切り替えができます。VSIXを手動で導入した場合は、新しいVSIXをcode --install-extension <file> --forceで導入し、Windowを再読込します。

自動取得したLanguage Serverは、拡張のglobal storageにあるservers内のadocweave-lsp-<version>-<target>形式のディレクトリへ置きます。同じ版を取得済みの場合は再取得せず、新しい版を取得したときは以前の版を削除します。取得する版を固定したい場合は、adocweave.server.pathまたはPATHで指定してください。

既知の制約

• 自動取得したLanguage Serverの版を拡張の設定から固定できません。常に最新の安定版を取得します。
• 自動取得ではattestationを検証しません。
• Marketplaceの索引更新には遅れがあり、公開直後は拡張画面へ現れないことがあります。

配布物の検証

対象Releaseのsha256.sumでarchiveを検査し、gh attestation verify <asset> --repo KeishiS/adocweaveでattestationを検証してください。

AdocWeave vscode 0.47.2

主な変更

• 必要なVisual Studio Codeの版を1.107.0以降へ下げました。 0.47.0は1.125.0以降を要求し、それより前の版では「not compatible with the current version of visual studio code」として導入できませんでした。1.107.0以降であれば導入できます。

機能の変更はありません。0.47.0を導入できている場合、この版で動作は変わりません。

下限を1.107.0とした理由を説明します。依存するvscode-languageclientが宣言する下限は1.91.0ですが、その版では拡張がCode Actionを返しません。宣言上の下限と、機能が実際に揃う版は別でした。実際のVisual Studio Codeで順に確かめ、Code Actionを含むすべての機能が揃う最小の版が1.107.0であることを確認しています。1.106.0では揃いません。

この版から、検査に使うVisual Studio Codeの版をengines.vscodeから導きます。宣言した対応範囲の下限そのもので、拡張の起動、診断、補完、定義への移動、Code Action、rename、semantic tokens、およびVSIXの導入、更新、rollback、削除を検証します。

対応環境

Visual Studio Code 1.107.0以降が必要です。拡張自体はplatformを選びませんが、別途導入するLanguage Serverは配布対象のtargetに従います。対応はlinuxのx86-64とARM64、macOSのARM64、Windowsのx86-64です。

対応関係

拡張とLanguage Serverは独立した製品で、版を揃える必要はありません。利用できる機能は、接続時に交換する標準LSP capabilityから決まります。

• 製品バージョン：0.47.2

v0.47.2への移行

• 利用者の作業は不要です。導入済みの環境では、拡張画面から通常どおり更新できます。
• 0.47.0を導入できなかった1.107.0以降の環境では、この版から導入できます。Visual Studio Codeを更新する必要はありません。
• 1.106.0以前をお使いの場合は、Visual Studio Codeの更新が必要です。

更新とロールバック

Visual Studio MarketplaceまたはOpen VSX Registryから導入した場合は、editorの拡張画面から更新および以前の版への切り替えができます。VSIXを手動で導入した場合は、新しいVSIXをcode --install-extension <file> --forceで導入し、Windowを再読込します。

既知の制約

• 拡張はLanguage Serverを同梱せず、取得もしません。別途導入が必要です。
• 未信頼ワークスペースでは拡張を起動しません。設定はmachine scopeに限定します。
• Marketplaceの索引更新には遅れがあり、公開直後は拡張画面へ現れないことがあります。

配布物の検証

対象Releaseのsha256.sumでarchiveを検査し、gh attestation verify <asset> --repo KeishiS/adocweaveでattestationを検証してください。

AdocWeave vscode 0.47.0

主な変更

• Visual Studio Marketplaceから導入できます。 これまでVisual Studio Code本体では、GitHub ReleaseのVSIXを取得して手動で導入する必要がありました。拡張画面からadocweave.adocweave-vscodeを検索して導入、更新および削除できます。公式の発行者はpublisheradocweaveです。
• 拡張はLanguage Serverを取得しなくなりました。 以前の版はadocweave-lspをeditorの保存領域へdownloadして管理していましたが、この処理を削除しました。利用者が導入した実行ファイルを、設定の絶対pathまたはPATHから探します。見つからない場合は導入案内を表示し、起動しません。
• 拡張とLanguage Serverの版を一致させる必要がなくなりました。 利用できる機能は、接続時に交換する標準LSP capabilityから決まります。lspApiVersionの一致を要求しません。

Open VSX Registryへも同じVSIXを公開します。どちらのregistryから導入しても、GitHub Releaseへ添付したfileと同一です。

対応環境

Visual Studio Code 1.125.0以降が必要です。拡張自体はplatformを選びませんが、別途導入するLanguage Serverは配布対象のtargetに従います。対応はlinuxのx86-64とARM64、macOSのARM64、Windowsのx86-64です。

対応関係

拡張とLanguage Serverは独立した製品で、版を揃える必要はありません。診断、補完および定義への移動などの利用可否は、Language Serverが返す標準LSP capabilityから判断します。標準capabilityがない機能は、editorのLSP clientが有効にしません。

• 製品バージョン：0.47.0

v0.47.0への移行

• 以前の版が自動取得したLanguage Serverを使っていた場合は、adocweave-lspを自分で導入し、PATHへ通すかadocweave.server.pathへ絶対pathを設定してください。導入手順は利用者向けの配布物導入文書を参照してください。
• 更新前に、旧版でadocweave.server.downloadをfalseにしてからAdocWeave: Remove Managed Language Serverを実行すると、使われなくなるキャッシュを確実に削除できます。更新後に気付いた場合の削除手順も同じ文書にあります。
• Marketplaceから導入し直す場合は、手動で入れたVSIXを先に削除してください。同じ識別子のため、二重には入りません。

更新とロールバック

Marketplaceまたは Open VSXから導入した場合は、editorの拡張画面から更新および以前の版への切り替えができます。VSIXを手動で導入した場合は、新しいVSIXをcode --install-extension <file> --forceで導入し、Windowを再読込します。rollbackでは以前のReleaseの検証済みVSIXを同じ方法で導入します。

既知の制約

• 拡張はLanguage Serverを同梱せず、取得もしません。別途導入が必要です。
• 未信頼ワークスペースでは拡張を起動しません。設定はmachine scopeに限定します。
• Marketplaceの索引更新には遅れがあり、公開直後は拡張画面へ現れないことがあります。

配布物の検証

対象Releaseのsha256.sumでarchiveを検査し、gh attestation verify <asset> --repo KeishiS/adocweaveでattestationを検証してください。

AdocWeave zed 0.47.0

主な変更

• Language Serverを自動で取得します。 これまでは拡張を導入しても、別途adocweave-lspを導入してPATHまたは設定へ登録するまで文書解析が動きませんでした。どちらにも見つからない場合、拡張がGitHub Releaseから最新のLanguage Serverを取得して起動します。
• 探索順は設定の絶対path、PATH、自動取得の三段です。 導入済みの実行ファイルがあれば常にそちらが選ばれ、自動取得は行われません。
• 自動取得にはchecksumとattestationの検証がありません。 Zedの拡張APIに検証手段がないためです。検証したうえで導入したい場合は、これまでどおりadocweave-lspを自分で導入し、lsp.adocweave.binary.pathまたはPATHで指定してください。

対応環境

自動取得はLinuxのx86-64とARM64、macOSのARM64、Windowsのx86-64に対応します。Intel macOSとWindows ARM64向けのnative archiveは配布していないため、これらの環境では自動取得へ進まず、対応環境を示して起動に失敗します。手動で導入した実行ファイルの指定は、この制限を受けません。

Zed Extension Galleryへ公開していないため、展開したディレクトリをdev extensionとして導入します。

対応関係

拡張とLanguage Serverの製品バージョンを一致させる必要はありません。利用できる機能は、接続時に交換する標準LSP capabilityから決まります。自動取得では、公開済みのadocweave-lspのうち最新の安定版を選びます。

• 製品バージョン：0.47.0

v0.47.0への移行

• 利用者の作業は不要です。すでにadocweave-lspを導入している場合、その実行ファイルが引き続き優先されます。
• 自動取得を使いたくない場合は、adocweave-lspを導入してlsp.adocweave.binary.pathまたはPATHで指定してください。拡張側に自動取得を止める設定は設けていません。

更新とロールバック

新しいバージョンのZedディレクトリを別に展開し、dev extensionをそのディレクトリへ再設定します。以前の版へ戻す場合は、同じ手順で古いディレクトリを指定し直します。旧ディレクトリは、新しい版で編集機能を確認するまで保持してください。

自動取得したLanguage Serverは、Zedが拡張へ割り当てるworkingディレクトリのadocweave-lsp-<version>へ置きます。拡張は取得した版だけを残し、以前の版を削除します。取得する版を固定したい場合は、lsp.adocweave.binary.pathまたはPATHで指定してください。

既知の制約

• 自動取得の完全性はTLSだけに依存します。checksumとattestationは検証しません。
• 自動取得するLanguage Serverの版を拡張の設定から固定できません。常に最新の安定版を取得します。
• Zed Extension Galleryへ公開していないため、dev extensionとして導入します。拡張自体の更新は自動化されません。

配布物の検証

対象Releaseのsha256.sumでarchiveを検査し、gh attestation verify <asset> --repo KeishiS/adocweaveでattestationを検証してください。

AdocWeave wasm 0.48.0

主な変更

• package名を @adocweave/browser から @adocweave/wasm へ変更しました。 WebAssemblyは静的サイト生成のようにNodeのビルド時でも動きます。動作環境を名前で限定しないよう、Rust crateと同じ wasm へ揃えました。@adocweave/browser は非推奨とし、移動先を示します。

• 成果物とtagの名前を変更しました。 成果物は adocweave-wasm-<version>.tgz、tagは adocweave-wasm/v<version> になります。

• 公開定数 BROWSER_PACKAGE_VERSION を WASM_PACKAGE_VERSION へ改名しました。

• Nodeからビルド時に使う入口 @adocweave/wasm/direct を追加しました。 静的サイト生成のようにNodeで解析と変換を行う場合、これまではpackageの内部layoutへ直接触れる必要がありました。同梱WebAssemblyを自分で初期化するため、pathを渡さずに使えます。要求と応答はブラウザー向けの入口と同じです。Web Workerを使わないため、取消しには対応せず、WebAssemblyがtrapした場合の分離もありません。処理を1つずつ順に実行する用途に限ります。

  import { analyze } from "@adocweave/wasm/direct";
  
  const result = await analyze({ sourceId, source, products: { html: true } });

AdocWeaveClient、defaultAssetUrls、analyze の要求と応答、WebAssemblyとの通信内容および解析結果は変えていません。

対応環境

WebAssemblyとWeb Workerに対応したブラウザーで動作します。公開entry、WorkerおよびWASMは同一originから配信します。

対応関係

WebAssemblyとの通信はschema handshakeで検査します。packageのバージョンを、AdocWeaveのほかの製品との互換性判断には使用しません。

• 製品バージョン：0.48.0
• WASM protocol schemaバージョン：15

v0.48.0への移行

• 依存の指定を @adocweave/wasm へ変更してください。@adocweave/browser へは新しい版を公開しません。
• BROWSER_PACKAGE_VERSION を参照している場合は WASM_PACKAGE_VERSION へ変更してください。
• GitHub Releaseのarchiveから導入している場合は、成果物名を adocweave-wasm-<version>.tgz へ変更してください。展開後のrootは package のままです。
• AdocWeaveClient の使い方は変わりません。
• packageの内部layoutを直接参照してNodeから使っていた場合は、@adocweave/wasm/direct へ切り替えられます。

更新とロールバック

npmから導入している場合は、指定するバージョンを変更して npm install を実行し、package-lock.json の差分を確認してください。archiveから導入している場合は、新しいarchiveを別のディレクトリへ展開し、worker/index.mjs と wasm の相対関係を保ったまま配備先を切り替えます。受入確認が終わるまで以前の状態を保持すると、問題がある場合に元へ戻せます。

既知の制約

• 一つのclientは同時に一つの解析だけを実行します。並行して解析する場合はclientを分けます。
• 取消しまたはWebAssemblyのtrapが発生した場合、clientはそのWorkerを終了します。同じWorkerとWASM instanceを次の解析へ再利用しません。
• HTMLの信頼方針は利用側が決めます。packageは出力を文字列として返します。

配布物の検証

対象Releaseのsha256.sumでarchiveを検査し、gh attestation verify <asset> --repo KeishiS/adocweaveでattestationを検証してください。

AdocWeave lib 0.47.0

主な変更

• Rustライブラリを版付きの製品として公開します。 これまでworkspace versionはどの製品にも属さず、公開APIを削除しても版が変わりませんでした。今後はadocweave-lib/v<version>のtagとGitHub Releaseを持ちます。利用側はcommit SHAではなくtagで固定できます。
• output::projectionからDocumentProjectionとprojectを削除しました。 用途別のquery関数へ分割しています。block_presentations、document_title、external_links、formulas、ordered_lists、reference_edges、rendering_featuresおよびsource_blocksが代わりです。
• output::conformanceからDocumentProducts、ProductSetおよびproductsを削除しました。 適合性検査の内部構造であり、公開範囲から外します。
• output::canonicalを追加しました。 canonical_astとcanonical_syntaxを公開します。

この版に含まれるcrateはadocweave、adocweave-config、adocweave-host、adocweave-textlintおよびadocweave-workspaceです。crates.ioへは公開しません。

対応環境

Rust 1.97.1で構築します。対応環境はRustのtoolchainに従います。

対応関係

CLI、Language Server、WebAssemblyおよびtextlint用Processorは、それぞれ独立した製品バージョンを持ちます。ライブラリの版をこれらとの互換性判断には使用しません。

• 製品バージョン：0.47.0

v0.47.0への移行

• gitの依存をtag = "adocweave-lib/v0.47.0"で固定できます。commit SHAでの固定も引き続き使えます。
• DocumentProjectionとprojectを使っていた場合は、必要な情報に対応するquery関数へ置き換えてください。文書全体を一度に組み立てる代わりに、使う値だけを取り出します。
• DocumentProducts、ProductSetおよびproductsを使っていた場合は、適合性検査の外ではoutput::canonicalの関数を使ってください。

更新とロールバック

利用側のCargo.tomlで固定するtagを変更し、cargo update -p adocweaveで解決し直してください。以前の版へ戻す場合は同じ手順でtagを戻します。Cargo.lockの差分で、解決したcommitを確認できます。

既知の制約

• crates.ioへ公開しません。gitの依存として取得します。
• 5つのcrateが同じ版を共有します。いずれかの変更で全体の版が上がります。

配布物の検証

対象Releaseのsha256.sumでarchiveを検査し、gh attestation verify <asset> --repo KeishiS/adocweaveでattestationを検証してください。

AdocWeave browser 0.47.0

主な変更

• 配布物の形式をnpmのtarballへ変更しました。 成果物の名前が adocweave-browser-<version>.tar.xz から adocweave-browser-<version>.tgz になり、展開後のrootが adocweave-browser-<version>/ から package/ になります。npm Registryへ公開する準備として、GitHub Releaseへ添付する成果物そのものをnpmの形式に揃えました。registry向けに構築し直さないため、どちらの経路でも同じbyte列を取得できます。
• packageのREADMEをMarkdownへ変更しました。 package registryのpackageページで描画できる形式にします。記載内容は変えていません。

公開API、WebAssemblyとの通信内容および解析結果は変えていません。

対応環境

WebAssemblyとWeb Workerに対応したブラウザーで動作します。公開entry、WorkerおよびWASMは同一originから配信します。

対応関係

WebAssemblyとの通信はschema handshakeで検査します。Browser packageのバージョンを、AdocWeaveのほかの製品との互換性判断には使用しません。

• 製品バージョン：0.47.0
• WASM protocol schemaバージョン：15

v0.47.0への移行

• GitHub Releaseのarchiveから導入している場合は、展開コマンドを tar -xzf へ変更してください。
• 展開後のディレクトリ名が package になります。adocweave-browser-<version> を前提にした移動やコピーの指定を変更してください。
• bundlerからの利用方法、公開API、defaultAssetUrls の使い方は変わりません。

更新とロールバック

新しいarchiveを別のディレクトリへ展開し、worker/index.mjs と wasm の相対関係を保ったまま配備先を切り替えてください。受入確認が終わるまで以前のディレクトリを保持すると、問題がある場合に元へ戻せます。

既知の制約

• 一つのclientは同時に一つの解析だけを実行します。並行して解析する場合はclientを分けます。
• 取消しまたはWebAssemblyのtrapが発生した場合、clientはそのWorkerを終了します。同じWorkerとWASM instanceを次の解析へ再利用しません。
• HTMLの信頼方針は利用側が決めます。packageは出力を文字列として返します。

配布物の検証

対象Releaseのsha256.sumでarchiveを検査し、gh attestation verify <asset> --repo KeishiS/adocweaveでattestationを検証してください。

AdocWeave textlint 0.47.0

主な変更

• enginesとpeerDependenciesを範囲指定へ緩めました。 従来はNode.js 24.19.0とtextlint 15.8.0へ完全一致で固定しており、動作する組合せでも導入時に警告や失敗が起きていました。今後はNode.js 24.19.0以上と、textlint 15.8系を受け入れます。CIで確認する組合せは変えていません。
• READMEをMarkdownへ変更しました。 package registryのpackageページで描画できる形式にします。記載内容は変えていません。

Processorの公開interface、TxtASTへの変換結果および診断の位置は変えていません。

対応環境

Node.js 24.19.0以上と、textlint 15.8系で動作します。WebAssemblyはパッケージへ同梱するため、Rust、Cargoまたは実行時の追加ダウンロードを必要としません。

対応関係

textlintのProcessor Pluginとして動作します。AdocWeaveのほかの製品を同じ環境へ導入する必要はありません。

• 製品バージョン：0.47.0

v0.47.0への移行

• 利用者の作業は不要です。依存の指定方法と設定は変わりません。
• Node.jsまたはtextlintのversionが合わず導入できなかった場合は、範囲指定へ緩めたことで導入できるようになります。

更新とロールバック

依存として記録したversionを新しい版へ変更し、npm installを実行してからpackage-lock.jsonの差分と検査結果を確認してください。以前の版へ戻す場合は、同じ手順で戻したいversionを指定します。受入確認が終わるまで以前のpackage-lock.jsonを保持すると、問題がある場合に元へ戻せます。

既知の制約

• includeを展開せず、入力された一つの物理ファイルだけを解析します。
• 自動修正に対応しません。規則が修正情報を返した場合も削除するため、textlint --fixでAsciiDoc文書を書き換えません。
• 一つの入力は10 MiB、TxtAST planは50 MiB、planのnodeは1,000,000件、sourceIdは4 KiBを上限とします。同梱WebAssemblyのlinear memoryは256 MiBを上限とします。

配布物の検証

対象Releaseのsha256.sumでarchiveを検査し、gh attestation verify <asset> --repo KeishiS/adocweaveでattestationを検証してください。