Hysen Labs
Open-source project
SpecterShell/Dumplings avatar
SpecterShell

Dumplings

Dump remote resources and lint outdated packages

52 stars31 forksPowerShellMIT
DEEP OPEN-SOURCE ANALYSIS

Dumplings automates WinGet manifest updates for Windows packages

A PowerShell project that monitors releases, builds manifests, and opens winget-pkgs pull requests.

What Dumplings does

Dumplings is a PowerShell automation project for monitoring Windows package releases, updating package state, generating and validating WinGet manifests, and submitting changes to the microsoft/winget-pkgs repository. The readme says the repository contains thousands of independent package tasks backed by a concurrent runner, static installer analyzers, manifest tooling, notification transports, and GitHub submission support. In practice it is a maintenance engine for the community package database that powers the Windows Package Manager. The runner can execute selected or all package tasks with explicit dependency ordering and configurable concurrency. It compares releases against persisted task state and distinguishes new, changed, updated, and rollback states, so it knows what moved. It detects and statically analyzes many Windows installer and bootstrapper formats. It can read, update, format, and validate multi file WinGet manifests without invoking winget validate. It writes task state, sends queued Telegram or Matrix notifications, and submits guarded pull requests. After each Automation workflow run it publishes a task status dashboard to GitHub Pages. A licensing note says the GPL installer implementations stay behind a JSON child process boundary from the Apache-2.0 PackageModule. The project reports 52 stars and 31 forks. The guarded pull requests mean a human can review each manifest change before it merges upstream.

Architecture and layout

The readme documents the architecture with a flowchart and a responsibility table. The Core is the runner that handles task discovery, dependency planning, worker coordination, hooks, timeouts, and synchronization. Modules/PackageModule holds the package task model, release helpers, installer analysis, WinGet manifest processing, messaging, and submission. Modules/InstallerParsers is a process isolated set of static parsers for formats whose implementations use GPL compatible licenses. The Tasks directory holds one folder per automation task, each with a Config.yaml, a Script.ps1, and persisted state. A .agents/skills directory carries workflow documentation for installer analysis and WinGet manifest authoring, and a Utilities directory holds repository maintenance and GitHub Actions support scripts. Core, PackageModule, and InstallerParsers are Git submodules and can also be used as independently versioned projects. The PackageModule's supported standalone entry point is Modules/PackageModule/PackageModule.psd1, and Core uses Modules/PackageModule/Index.ps1 to import that manifest and load the task model classes. The JSON child process boundary between PackageModule and InstallerParsers is a deliberate isolation: the GPL licensed parser code runs in a separate process so the Apache-2.0 module that most consumers touch stays cleanly separated. This separation matters for anyone who wants to reuse parts of Dumplings without taking on the GPL parser license. The submodules let each layer be versioned and released on its own cadence.

Requirements and usage

Running Dumplings has clear requirements. It needs Windows, PowerShell 7.4 or later, Git with submodule support, network access for release checks and installer downloads, and GitHub credentials, with an optional local winget-pkgs checkout only when submission is enabled. The runner installs missing PowerShell modules declared in Preference.yaml, and GitHub Actions uses pinned versions from PowerShellModules.psd1 with caching between runs. An optional browser helper restores the Apache-2.0 Patchright runtime pinned by PlaywrightRuntime.psd1, with its large driver payload cached outside Git rather than committed. Getting started means cloning with submodules, or running git submodule update to fetch them after a plain clone. A single task can be run without writing state, sending messages, or submitting, using Core/Index.ps1 with a name such as Adobe.WorkfrontProof. Several tasks can run with a throttle limit of four workers. Running every task uses Core/Index.ps1 with no name filter. Common switches override Preference.yaml values: a force flag re evaluates a task regardless of state, enable write persists State.yaml and a timestamped log after a detected change, and several other operational flags tune behavior. The project is published under the MIT license. The combination of concurrency, static analysis, and guarded submissions makes it a practical maintainer tool for the winget ecosystem.

Editorial conclusion

The repository is published under the MIT license and its most recent commit was on 2026-08-26.

DEEP OPEN-SOURCE ANALYSIS

Official sources

Community notes

Community notes