CPANscan

CPANSA::DB provides the CPAN Security Advisory dataset as a ready-to-use Perl data structure. It exposes a single subroutine, db, which returns a hashref containing all advisories and is primarily used by CPAN::Audit but can be used by any code that needs programmatic access to CPAN security reports. Each release includes a .gpg signature and GitHub attestations so you can verify the archive and module file, and a JSON file with the same data is also available for non-Perl consumers. The project is published on GitHub with attestations and GPG signatures to help ensure you are using authentic advisory data.

Dist::Zilla::PluginBundle::Codeberg is a convenience bundle for Dist::Zilla that wires in Codeberg support so you can publish and maintain CPAN distributions hosted on Codeberg. It automatically adds the Codeberg::Meta and Codeberg::Update plugins to populate META fields like homepage, bugtracker and wiki and to create or update the remote repository, and it picks up your Codeberg credentials from git config or an optional ~/.codeberg file created by Config::Identity; you must create a personal access token with the api scope. Configuration options let you control which homepage or bug URL gets written, which git remote to inspect, whether to follow upstream forks, and the explicit repo name when needed. If you use Dist::Zilla for releasing modules and host your code on Codeberg this bundle saves manual metadata and repo setup work. Recent releases update the module to use the Forgejo/Codeberg API and remove the installer entry from dist.ini.

Dist::Zilla::PluginBundle::GEEKRUTH is an opinionated, ready-made Dist::Zilla configuration that bundles and preconfigures the collection of plugins D. Ruth Holloway uses to build, test, version and release Perl distributions. It automates common release work such as contributor tracking, metadata (MetaYAML/MetaJSON), POD weaving and README generation, compile and release tests, automatic prerequisite detection, changelog and semantic versioning, and the git commit/tag/push steps so you do not have to assemble all those pieces yourself. You can tweak a few arguments like authority (default cpan:GEEKRUTH), builder (default MakeMaker), development and release branch names, upstream remote, autoprereqs_skip and a remove_plugin option to drop parts you do not want. This bundle is most useful if you want a proven, full-featured release pipeline modeled on Ruthie’s workflow rather than a minimal or highly bespoke setup. Recent notable changes moved the workflow to Codeberg and added a SecurityPolicy plugin.

Mojolicious::Plugin::Fondation::Setup provides an interactive web-based setup wizard for Fondation applications that discovers available plugins on MetaCPAN, reads each plugin's declared setup metadata, and builds a step-by-step configuration workflow served at /setup. Users can pick which plugins to enable, complete per-plugin configuration screens whose fields are pre-filled from any existing config, and persist progress using a file-backed workflow so no database is required. When the wizard completes it writes a $moniker.conf file with the selected plugins and their settings and shows a confirmation page, and it will warn if Mojolicious::Plugin::Config is not enabled so you know to load the generated config. This plugin is a convenient way to assemble and configure Fondation plugins through a guided UI rather than hand-editing configuration.

Mojolicious::Plugin::Fondation::Layout::Bootstrap is a small plugin for the Mojolicious web framework that provides a ready-made Bootstrap-based page layout for projects following the Fondation convention. It helps developers drop a consistent, responsive layout into their Mojolicious apps without writing repetitive template code, making it easier to get a Bootstrap look and structure up and running quickly. The module is intentionally lightweight and focused on layout, so it integrates easily with existing application code and other plugins.

UTF8::R2 is a pragmatic Perl module that gives you explicit UTF-8 codepoint handling without flipping Perl's internal UTF8 flag, so existing byte-oriented programs keep behaving and you avoid common mojibake problems. By importing its mb namespace you get mb::length, mb::substr, mb::tr and other mb:: helpers and you use a $mb{qr/...} wrapper to build regular expressions that match Unicode codepoints rather than raw octets. It supports several UTF-8 variants including RFC3629, RFC2279, WTF-8 and ja_JP-optimized forms, runs on Perl 5.005_03 and later, and deliberately leaves core built-ins working in octet semantics so you opt in to multibyte behavior only where you call the mb APIs. This makes the module useful for porting old scripts or for developers who want clear, noninvasive UTF-8 handling, with the trade off that it only supports UTF-8 encodings and requires the mb:: function names and $mb{qr/...} form for codepoint-aware operations.

Chandra::Markdown is a small helper for Chandra web apps that converts Markdown into HTML and integrates it into your app UI, making it easy to display documentation or content pages. You create it with a reference to your Chandra app and then use render to get HTML or set/append to update a target element in the webview; it supports GitHub-flavored Markdown and has options for line break behavior and built-in CSS. It can also scan a directory of .md files, register routes for each file, produce a navigation block, and build a searchable index that you can query with search or expose to users via a ready-made search_widget that registers the necessary invoke handler. This initial release provides the basic rendering, routing, navigation and search features you need to serve Markdown-based docs inside a Chandra application.

Mojolicious::Plugin::Fondation is a plugin manager for Mojolicious that makes it easy to assemble a web app from modular "bricks" by loading plugins recursively, merging their configurations, and sharing their templates and static assets with the main application. It resolves plugin dependencies and soft ordering, combines configuration from direct parameters, app config files and plugin defaults with predictable merge rules, and automatically registers plugin templates, controllers and public assets through post-load actions that you can extend with custom action classes. Fondation also provides a registry and helpers, supports zones so plugins can inject HTML or JavaScript into named layout areas, and offers a deferred finalization hook for plugins to run code after everything else is loaded. It is ideal if you want to compose a modular application where many plugins contribute routes and resources while avoiding duplicate loads and managing priorities. Note that to be fully recorded and receive the finalization callback a plugin must return $self from its register method.

Markdown::Simple is a compact, high-performance Perl module that converts Markdown to HTML with GitHub Flavored Markdown as the default and an easy functional call markdown_to_html or an object interface for reusing the parser across many renders. You can switch to strict CommonMark or toggle individual features like tables, strikethrough, task lists and autolinking, control soft-break behavior, and strip Markdown to plain text with strip_markdown. The implementation is in XS and includes SIMD acceleration on supported CPUs for much faster rendering, and recent releases have focused on portability and build fixes across platforms such as OpenBSD. Use it when you want a fast, configurable Markdown-to-HTML converter in Perl, especially for batch or high-throughput workflows.

Mojolicious::Plugin::Fondation::Workflow::UI::Bootstrap provides five template helpers that render Bootstrap 5 UI elements for Fondation::Workflow objects so you can quickly add workflow displays and controls to Mojolicious EP templates. The helpers return ready-to-embed HTML when given a Fondation::Workflow::Proxy and include workflow_state, which renders a colored badge using per-state fondation metadata for label, color and icon; workflow_actions, which builds a Bootstrap button group with data-action and optional confirmation text for each available action; workflow_progress, which prints a text-based state tree that highlights current, visited and future states using history-aware backtracking and cycle detection; workflow_history, which emits a vertical timeline of all history entries; and workflow_graph, which returns a raw Mermaid.js flowchart definition for inclusion in a pre block with class mermaid or for external rendering. The plugin requires Fondation::Layout::Bootstrap and Fondation::Workflow, falls back to raw names and bg-secondary when fondation metadata is absent, and returns an empty string when passed undef or an invalid workflow.

Search::Trigram is a lightweight Perl module that builds a trigram-based inverted index for fast, approximate text search and ranking. You add UTF-8 documents to the index and then query with short phrases; results are returned as scored matches (doc_id, score, text) ranked by Dice coefficient over shared trigrams, with a default result limit of 10. The module treats trigrams case-insensitively at the UTF-8 byte level, lets you mark documents as deleted, and provides an optimize operation to compact posting lists and purge deletions. It also exposes simple counters for live documents and distinct trigrams, making it a handy choice when you need quick fuzzy substring matching without a heavyweight search engine.

Mojolicious::Plugin::Fondation::Workflow brings the Workflow CPAN state-machine into the Fondation Mojolicious world, providing a controller helper to create and fetch workflows and a Proxy wrapper with convenient methods such as actions, state_fondation, execute and history. Workflows are defined as YAML files extended with Fondation UI metadata used by a Bootstrap renderer and can persist either via a DBI persister for full apps or a file persister for DB-free wizards, so setup flows can run without a database. Per-workflow persister settings are supported and the plugin will warn rather than fail if no DSN is configured. When Fondation::User is present the plugin also wires a belongs_to relation so workflow history entries can resolve back to users without adding a hard dependency. This module is a good fit for Fondation apps that need authorized, UI-driven state machines. Initial release provides the workflow helper, the Proxy object and basic authorization integration.

Tk::ColorEntry is a small Perl/Tk megawidget that combines a text entry with a colored indicator to make picking and showing colors in a GUI simple and intuitive. The indicator shows the current color beside the entry and clicking the entry opens a pop-up color picker; you can react to selections with a -command callback or bind the value to a variable with -variable so your application stays in sync. It supports the same options and methods as Tk::ColorPicker and offers get and put methods for programmatic access, highlights invalid color text with a configurable error color, and lets Escape dismiss the picker or cancel a pick operation. The module is handy for forms, editors, or graphical tools that need quick color input, and recent updates improved history handling and switched the history page to use Tk::ListBrowser while allowing multiple ColorEntry widgets to share a PopColor widget.

RPi::Const provides a ready-made set of named constants for Raspberry Pi embedded work and for the RPi::WiringPi family of Perl modules, making GPIO code clearer and less error prone by letting you import groups of constants such as pin numbering modes, pin input/output and alternate modes, pull-up/down resistor settings, logical HIGH and LOW, PWM modes and defaults, interrupt edge types, and detailed register addresses and pin aliases for the MCP23017 GPIO expander; constants are exported by tag like :all or more focused tags so you only pull in what you need, and the suite intentionally does not include a physical-pin setup tag.

Workflow is a standalone Perl workflow engine for modeling processes as states, actions and guarded transitions that you can embed into your application. You define workflows, actions, conditions and validators in configuration (YAML is now preferred and XML support is deprecated) and use Workflow::Factory to create or fetch Workflow instances that carry a Workflow::Context as a simple blackboard for application data. Actions perform work and can declare required input fields and validators while conditions control availability, and the engine exposes discoverable action lists and field metadata so UIs can be driven from the workflow definition. The system is extensible and pluggable with custom action, condition, validator and history classes, observer hooks for lifecycle events, and persister backends for DBI, file or custom storage. Recent maintenance includes a 2.10 bug fix for context handling when given an unblessed hashref and prior releases added event improvements and the migration away from XML configuration. If you need a flexible, discoverable state machine that integrates with your own storage and business logic, Workflow is a practical, well‑maintained option with examples and an active issue tracker.

Crypt::OpenSSL::X509 is a Perl extension that gives you direct access to OpenSSL's X.509 certificate functionality so your Perl scripts can load and inspect certificates in PEM or DER form. It provides simple constructors and lets you read subject and issuer names, serials, validity windows, public key details and modulus, email addresses and Subject Alternative Names, extensions (by OID or name), fingerprints (MD5 and various SHA digests), and export the certificate back to PEM or ASN.1. The module supports a wide range of OpenSSL and LibreSSL versions, including compatibility fixes for OpenSSL 4.x, and is handy for automation, monitoring, or tooling that needs to parse or validate X.509 certificates. Recent releases addressed OpenSSL 4.x API changes and 2.1.2 fixed a bug where extension lookups were accidentally shared across certificate objects by making the extension cache per-instance, so upgrading is recommended if you instantiate multiple certificates in the same process.

Imager::File::WEBP is a plug‑in for the Imager library that adds reading and writing support for WebP images so you can load .webp files into Imager and save images as WebP with either lossy or lossless compression. It exposes simple tags for mode and quality plus a richer Config object for advanced libwebp options such as target file size, near‑lossless, threading, alpha handling and other encoder tuning parameters, and it supports animated WebP features like loop count, frame duration, frame position, blending and disposal. Grayscale images are written as RGB because of WebP limitations and EXIF metadata is available only when built against a recent Imager/libwebp build. To use it you need Imager plus libwebp and the libwebpmux component, and the module also provides a function to report the encoder ABI version so you can check which features are supported.

Mojolicious::Plugin::Fondation::Asset is a small helper for Mojolicious apps using the Fondation ecosystem that wraps AssetPack so asset definitions from many plugins can be merged and preprocessed into a single assets/assetpack.def file via the included "asset generate" command. The generator collects and merges per-plugin asset definitions, normalizes remote fetch directives so external URLs are handled correctly, and processes bundles so external files are cached and not re-downloaded during runtime. On startup the plugin will only load AssetPack and register plugin public directories if the merged assetpack.def exists, otherwise it logs a warning and allows the app to continue so you can run the generator as a separate step. This is aimed at developers who want a reproducible, centralized asset build for Fondation-based Mojolicious apps, and version 0.02 adds a 'setup' option for plugin configuration.

Tk::DocumentTree is a Perl/Tk megawidget that provides a simple file or document browser by combining a label with an ITree widget and automatically building a folder hierarchy as you add entries. It shows the common path for all entries in the label, supports entries marked as regular files or as untracked items, and uses icons to indicate file, folder and modified/saved status with customizable callbacks for supplying icons and handling selection. The widget exposes convenient methods to add, delete, select and reveal entries, mark entries modified or saved, expand or collapse the tree, and retrieve lists of tracked or untracked files. It accepts most ITree options but reserves a few (for example -itemtype, -browsecmd, -separator, -selectmode and -exportselection) and ships with sensible default icons and a right‑click context menu that you can customize. This module is a good fit for Perl/Tk applications that need an integrated, editable document or project tree without building the widget from scratch.

DBIO::PostgreSQL::EV provides real non‑blocking PostgreSQL access for the DBIO framework by wiring DBIO to EV::Pg and libpq's async protocol, delivering async select/insert/update/delete operations, transactions, pipelining, LISTEN/NOTIFY, COPY IN, deploy_async and an async-aware connection pool while keeping normal synchronous DBI behaviour intact. The distribution itself is mainly a marker that you load into your schema to enable the "ev" async backend and the actual asynchronous implementation lives in DBIO::PostgreSQL::EV::Storage, with async mode enabled explicitly per connection using { async => 'ev' } at connect time. It integrates with the EV event loop and therefore works with AnyEvent, IO::Async (via EV) and Mojolicious, and when not opted into async the code falls back to the documented sync or forked fallback paths so existing code keeps working. Recent releases clarified the per‑connection opt‑in, renamed the distribution and namespaces to reflect the EV driver, and consolidated the storage on the core async machinery while fixing pooling, transaction and COPY race issues for more robust live use.

DBIO::PostgreSQL::PostGIS adds first-class PostGIS support to DBIO::PostgreSQL result classes so your spatial columns behave like native objects instead of raw text. Columns declared as geometry or geography are automatically inflated to lightweight Geometry objects on read and converted back to EWKT for writes. The module also injects spatial query helpers into resultsets for common operations such as distance searches, nearest neighbor ordering and standard spatial predicates, and it provides schema-level helpers like ensure_postgis and postgis_version for managing the extension. If you use DBIO with a PostGIS-enabled database this saves you from manual WKT/EWKT handling and makes spatial queries feel like ordinary resultset methods. Recent releases make PostGIS a registered storage layer instead of a storage_type override and improve error handling so missing-extension checks and internal parse errors now throw DBIO::Exception with clearer messages.

DBIO::Oracle is a lightweight adapter that makes DBIO talk to Oracle databases by automatically wiring your schema to the Oracle-specific storage and SQL dialect when you connect. Instead of changing your application logic this module simply ensures DBIO uses DBIO::Oracle::Storage (the -ora shortcut does this for you) and it includes sensible Oracle behaviors such as sequence-based auto-increment, LOB binding, RETURNING support, ROWNUM limit/offset handling, and a pre-9.0 fallback for non-ANSI joins. It is not a full ORM rewrite but the canonical way to run DBIO against Oracle engines and to pick up the complementary components for SQL generation, introspection, DDL and deployment. Recent fixes make identifier quoting safer by leaving Oracle pseudo-columns like LEVEL and ROWNUM unquoted to avoid ORA-00904, correct LOB type detection for bindings, and now require DBD::Oracle as a hard dependency so you get a working Oracle driver at install time.

DBIO::MySQL::EV provides non-blocking MySQL and MariaDB storage for the DBIO framework by talking directly to the database via EV::MariaDB instead of DBI, so queries return Future objects and you can run true async operations from an EV-based event loop. It is opt-in per connection by passing { async => 'ev' } to Schema->connect and is installed as a schema component so your existing DBIO resultset calls gain *_async variants that pipeline automatically at the wire level and use prepared statements for bound queries, while the synchronous methods remain available but will block the event loop. The module handles transactions, connection pooling with per-transaction pinning, and adapts INSERTs to MySQL by assembling returned-column hashrefs from LAST_INSERT_ID(), and it works with EV directly or with AnyEvent, IO::Async via Loop::EV, or Mojolicious. Recent releases refactor the storage into a thin transport over DBIO::Storage::Async for a smaller, shared core implementation and fix several production issues such as connection readiness, stale bind handling, and pooled-connection bugs, making the EV backend more robust and maintainable.

DBIO::PostgreSQL::Age adds Apache AGE graph database features to DBIO::PostgreSQL so you can manage named graphs and run openCypher queries from the DBIO stack. It installs a storage layer that composes over the existing PostgreSQL driver, so graph capabilities stack cleanly with other extensions and work on async transports, and you enable AGE on each connection with the provided load_age on_connect callback. The module exposes graph lifecycle operations like create_graph and drop_graph and a cypher() method to execute parameterized Cypher and return decoded results, with a new decode_agtype helper and an auto_decode option to turn AGE agtype cells into native Perl structures. The recent release makes AGE a true composable layer instead of hijacking the Pg driver, fixes a registration bug that could affect plain DBI connections, improves async dispatch, and standardizes connection replay for LOAD 'age' and search_path setup so the feature is safer and more interoperable.

DBIO::MSSQL is a tiny DBIO subclass that makes working with Microsoft SQL Server easy by automatically wiring your schema to the DBIO::MSSQL::Storage backend when you connect, so you can just "use DBIO 'Schema', -ms" and get MSSQL-aware storage, SQL generation and schema-management behavior without hand‑wiring the driver. It is the entry point for the MSSQL features in the DBIO family, including native DDL/introspection, schema diffs and deploys, SQL dialect tweaks for LIMIT/OFFSET and identity/GUID handling, and a Sybase/FreeTDS compatibility path when needed. If you use DBD::ODBC the recent patch adds a dedicated DBIO::MSSQL::Storage::ODBC class and fixes a schema-diff bug that could abort when a removed table and one of its indexes were dropped in the same operation, while also correcting FreeTDS version handling. Use this module when your application uses the DBIO ORM and your database is Microsoft SQL Server, otherwise you do not need it.

DBIO::GraphQL automatically builds an executable GraphQL schema from a connected DBIO::Schema by introspecting your tables and exposing columns as typed scalar fields, relationships as object or list fields, root Query operations for single lookups and plural allXs queries with nested per-column filters, ordering, offset and cursor pagination, and root Mutations for createX, updateX and deleteX. It supports composite primary keys and maps common SQL types to GraphQL Int, Float, Boolean, or String while translating DBIO search-condition syntax into typed filter inputs with logical AND/OR. Mutations surface database errors as GraphQL errors and delete returns false when a row is not found. Known limitations are that relationship fields are unfiltered, mutations accept only scalar column values and updates are full-row, custom scalars and subscriptions are not generated, and cursor pagination only advances correctly when ordering by the primary key. The to_graphql method returns a GraphQL::Schema plus the original DBIO schema as context so you can call GraphQL::Execution::execute directly. A recent release fixed a security issue by validating orderBy.field against the source columns to prevent SQL injection and improved error handling for unknown columns.

DBIO::Forked is a lightweight, dependency-free adapter that turns any synchronous DBIO/DBI driver into an asynchronous one by running queries in short-lived forked children and streaming results back to the parent over a pipe. You enable it per connection with { async => 'forked' } and the connection immediately returns a DBIO::Forked::Future so your main program can continue while the child does the blocking work. It requires only core Perl functions and modules so it works with drivers that lack native async bindings such as Oracle, SQLite, DB2, and Sybase, and it does not pull in an event loop or extra client libraries. Transactions are handled by running an entire txn_do_async block inside a single child process, so the block is non-blocking to the parent but individual statements inside the transaction are not interleaved with an event loop and you cannot issue per-statement async calls on a pinned transaction. Results and transaction returns must be Storable-serializable and nested async calls inside a transaction body are not supported. This is the first release, providing a generic, fork-based async storage backend that complements DBIO::Async for drivers that will never get native async clients.

DBIO::Firebird is a tiny DBIO schema component that makes DBIO-based applications talk to Firebird and InterBase databases by automatically selecting DBIO::Firebird::Storage when you connect. Load it into your schema or use the provided "use DBIO 'Schema', -fb" shortcut and your DBIO->connect calls will use the Firebird/InterBase storage implementation without extra wiring. It is aimed at developers who use DBIO as their ORM and need native Firebird/InterBase support via DBD::Firebird, including introspection, DDL generation, and diff/deploy features provided by the companion storage modules. In the recent 0.900001 release a full-schema sync bug was fixed so that a DROP INDEX will no longer conflict with a concurrent DROP TABLE during apply/upgrade, and the distribution now requires DBD::Firebird as a hard dependency.

DBIO::DuckDB is a DBIO schema component that adds first-class DuckDB support to DBIO-based applications by forcing the storage class to DBIO::DuckDB::Storage and using DBD::DuckDB to talk to an embedded DuckDB instance. It preserves the familiar DBI/ORM behavior for transactions, binds, cursors and result sets while exposing DuckDB-native capabilities such as the Appender API for fast bulk inserts, an Arrow-oriented columnar fetch path, convenient read_csv/read_parquet/read_json table-function helpers, extension and checkpoint helpers, and Quack client/server hooks. The module also provides a PostgreSQL-flavored SQL dialect, introspection of DuckDB metadata, and a deploy/diff workflow that test-deploys and compares schemas to generate safe DDL changes. Tests run against in-memory DuckDB databases so no external credentials are needed, and a handy -du shortcut is provided for easy loading. The recent release makes driver errors throw DBIO::Exception objects for consistent error handling and fixes a DROP INDEX versus DROP TABLE collision during full-schema sync; it requires DBIO >= 0.900001.

DBIO::DB2 is a tiny DBIO subclass that makes it trivial to target IBM DB2 by automatically wiring your schema to the DB2-specific storage driver when you connect. Load it into your DBIO schema or use the provided -db2 shortcut and DBIO will use DBIO::DB2::Storage so your application can take advantage of DB2-aware introspection, DDL generation, schema diffing and deployment without having to name the storage class yourself. It is the right choice if you use DBIO as your ORM and need seamless support for DB2 databases. The recent 0.900001 release fixed a schema-diff edge case that could emit conflicting DROP INDEX and DROP TABLE statements and now suppresses standalone index drops when their table is also being dropped, and the distribution now requires DBD::DB2 and DBIO >= 0.900001.