React Cosmos is a component development environment for React. In production it operates as a developer tool running a Node.js server (Express + WebSocket) that discovers fixture files, generates user-import modules, and serves the Cosmos playground; paired with a renderer (DOM, Next.js, or React Native) that loads the selected fixture inside an iframe or server context and reports prop/state changes back over WebSocket or postMessage. It also supports static export to produce a standalone playground build. The repository is a library/CLI tool, not a deployed application. Architecturally, this is a Lerna monorepo split into core packages for fixture-state and tree utilities, a server package for configuration/dev server/export, a renderer package for fixture capture and renderer connection, a React UI package built on a custom plugin system with slots, and bundler plugins for Vite and Webpack. The core workflow is fixture-based: developers write .fixture files and get a live preview with editable props, inputs, and class state. Entry points include bin/cosmos.js, bin/cosmos-export.js, and programmatic APIs such as detectCosmosConfig and getFixtures. Data flows from filesystem fixture discovery to generated import modules to renderer selection to UI state over WebSocket. External dependencies include React, Express, ws, Vite/Webpack, Next.js for server components, and React Native for native support. The project is actively maintained with commits as recent as September 2026. Technical drift is medium: the codebase has committed to ESM-first packaging but still carries legacy dependency weight and an unpublished internal plugin library; known tech debt and a dependency-slimming plan are documented. No data science or research components are present.
tmuxp is a CLI tool and Python library for managing tmux sessions declaratively. It loads, freezes, converts, and imports workspace configurations in YAML or JSON formats, enabling reproducible tmux environments. The architecture follows a layered design: configuration files are parsed by a custom config reader, expanded with environment variables and shorthand forms, then processed through a `trickle` function that propagates defaults across session/window/pane hierarchy. A workspace builder (default is `ClassicWorkspaceBuilder`) translates the expanded config into tmux commands via the libtmux library, creating sessions, windows, panes, and executing shell commands. A plugin system allows custom workspace builders and lifecycle hooks (`before_workspace_builder`, `on_window_create`, `after_window_finished`, `before_script`, `reattach`). The CLI supports subcommands (load, freeze, convert, import, edit, ls, search, shell, debug-info) with structured output modes (human, JSON, NDJSON), semantic color support, and a thread-based progress spinner. External dependencies are minimal: Python ≥3.10, tmux ≥3.2, and libtmux ≈0.61.0. The codebase demonstrates strong engineering practices with extensive integration tests against multiple tmux versions, Sphinx documentation, and a well-defined plugin contract.
pkg-types is a small, ESM-only TypeScript library that provides utilities and type definitions for Node.js configuration files. In production it is consumed as a dependency rather than run as a service: callers use functions such as readPackageJSON, readTSConfig, findWorkspaceDir, resolveLockfile, parseGitConfig, and sortPackage to locate, parse, serialize, and manipulate package.json, tsconfig.json, and .git/config files. It supports package.json, package.json5, package.yaml, JSONC, JSON5, YAML, and git INI formats, with lazy parser loading for JSON5/YAML to keep cold-start cost low. The code is organized into four small vertical slices — resolve, packagejson, tsconfig, and gitconfig — all re-exported from src/index.ts. Path resolution uses exsolve for module-style imports and pathe for cross-platform paths; parsing is delegated to confbox. The primary data flow is simple: an input path is resolved to the nearest or farthest matching file, the file is read and parsed into a typed object, and optionally written back after mutation. There are no API endpoints, data stores, or background processes. Notable implementations include a boundary-aware nearest/farthest file finder that stops at node_modules, workspace directory detection from pnpm/lerna/turbo/rush/deno markers or git config/lockfiles, a Proxy-based updatePackage that auto-creates common package.json map fields during mutation, deterministic package.json sorting/normalizing, and conversion of git's subsection INI format ([remote "origin"]) into generic dotted INI keys for parsing and back on stringify. The project has solid Vitest coverage, type-level tests, and modern CI using oxlint, oxfmt, and obuild. One minor limitation is that git config subsection round-tripping is regex-based and not fully robust for unusual subsection names containing slashes or other non-word characters.
https-localhost is a developer tool that runs an HTTPS server on localhost using locally-trusted SSL certificates. It downloads the mkcert binary appropriate for the host OS/architecture, executes it to install a local CA into system/browser trust stores, and generates per-host certificates. The resulting HTTPS server can either serve static files from a directory or act as a reverse proxy to an existing HTTP/HTTPS server, with optional HTTP-to-HTTPS redirection. It ships as both a global CLI (the `serve` binary) and a programmatic API (`createServer()`, `getCerts()`). Architecturally it is a small, well-separated set of ES modules built directly on Node's built-in http/https servers with no framework dependency. The router dispatches between a static file handler and a proxy handler; CORS headers are applied globally; environment/CLI configuration is validated through a zod schema where CLI flags take precedence over environment variables. External runtime dependencies are deliberately minimal: only `mrmime` for MIME lookup and `zod` for config validation, plus the downloaded mkcert binary. The static handler is the strongest piece: it implements path-traversal sanitization, ETag/Last-Modified conditional requests, byte-range responses (206/416), HEAD/OPTIONS support, directory index serving with query-preserving trailing-slash redirects, and custom 404.html lookup. The proxy handler strips hop-by-hop headers, injects X-Forwarded-* headers, tunnels WebSocket upgrades, and cleanly returns 502 when upstreams fail or die mid-response. Test coverage is comprehensive and genuinely exercises real sockets: unit tests for env parsing and certificate lifecycle, integration tests for static serving and proxying, CLI spawn tests, and edge-case tests for malformed percent-encoding, CORS preflight without upstream contact, and client hang prevention. CI runs a matrix across Ubuntu/macOS and Node 24/26 with strict type-aware linting, dead-code detection (knip), and formatting checks. Minor weaknesses: synchronous fs calls in the static handler (fine for a dev tool), a `process.exit()` call inside library code for unsupported platforms, minimal error handling in the mkcert download routine (only follows 302s, ignores non-2xx statuses), and no Windows CI coverage despite Windows-specific code paths.
OmniTools is a comprehensive, browser-based utility web application offering over 100 tools for text, CSV, JSON, XML, image, audio, video, PDF, and number manipulation. All processing occurs client-side using WebAssembly (FFmpeg, Ghostscript, Tesseract) and pure JavaScript, ensuring no data leaves the user's device. The application is built with React 18, TypeScript, Material UI, and Vite, and is fully internationalized with 11 languages. It follows a consistent tool architecture: each tool is defined via a `defineTool()` function with metadata, lazy-loaded components, and a uniform UI pattern using `ToolContent` wrapper, reusable input/result components, and dynamic option rendering. The codebase demonstrates strong engineering practices with extensive unit tests (Vitest), end-to-end tests (Playwright), CI/CD pipelines (GitHub Actions, Docker multi-platform builds, Netlify deployment), and a well-organized file structure. While the project is actively maintained and well-crafted, it exhibits some boilerplate duplication across tools and a large dependency surface that could introduce maintenance overhead.
This repository is a curated collection of tips, scripts, and a Claude Code plugin (dx) that enhances developer workflows with Claude Code. It is primarily a knowledge base and tooling repository, not a standalone application. The core deliverable is the dx plugin, which bundles skills for GitHub Actions debugging, conversation half/quarter-cloning, context handoffs, Reddit/HN research, private GitHub search, and version checks. The repository also includes a custom status line script (context-bar.sh), a setup script for recommended configurations, and extensive markdown content documenting 49 tips for using Claude Code effectively. The architecture is a mix of bash scripts, skill definitions (markdown with YAML frontmatter), and a plugin manifest. The standout component is the half-clone-conversation.sh script, a 400+ line bash utility that clones Claude Code conversations with careful edge-case handling, cross-platform support (macOS, Linux, Windows Git Bash), and a comprehensive 19-test suite. The repository demonstrates high craftsmanship in its bash scripting, thorough testing, and detailed documentation of workarounds for platform limitations (e.g., Reddit's blocking, GitHub's private repo search).
Murex is a cross-platform shell and scripting language designed as a more readable, safe, and type-aware alternative to Bash. In production it works as both an interactive REPL (with autocomplete, hint text, preview panes, spellchecking, and job control) and a scripting interpreter with a custom expression language, typed pipelines, exception handling (try/catch/trypipe), multi-scope variables, a built-in unit test framework, event hooks (onPrompt, onKeyPress, onFileSystemChange, onSignalReceived), an HTTP client, and a package/module manager. The defining architectural feature is that data in pipelines carries type metadata: JSON, YAML, CSV, TOML, XML, S-expressions, HCL and more are first-class structured objects with registered Marshal/Unmarshal/ReadArray/ReadMap/ReadIndex hooks, so builtins like alter, tabulate, count, and jsplit operate on structured data rather than raw text. The implementation is Go (with a JS/WASM interpreter variant), organized around lang/ (parser, expression engine, process lifecycle), shell/ (interactive terminal layer), builtins/ (roughly 200 commands, data type adapters, pipes, and event handlers), config/ (profile-driven runtime configuration), and utils/ (standalone helper libraries).
Responsively App is an Electron-based desktop application for responsive web development testing. It allows developers to preview a website across multiple device simulators simultaneously (phones, tablets, laptops) with synchronized interactions such as scrolling, clicking, and form input mirroring via BrowserSync. The application includes a built-in MCP (Model Context Protocol) server that exposes automation tools (navigate, screenshot, click, read_page) for AI coding agents like Claude Code and Cursor. It also provides design overlays, color blindness simulation, ruler/guide systems, and screenshot capture. The codebase is structured as a monorepo with three packages: the desktop app (Electron + React + Redux), a browser extension (Manifest V3) to open URLs in the app, and an MCP CLI package published to npm. The architecture follows a main-process/renderer split with IPC communication, extensive E2E tests (Playwright), and a device frame system with pixel-accurate bezel artwork generated from upstream sources.
RedisInsight is a full-stack graphical user interface for managing and interacting with Redis databases. It is built as an Electron desktop application with a React frontend (utilizing styled-components and a custom component library) and a NestJS backend that communicates with Redis instances. The application covers a wide range of Redis features: key-value browser with support for all data types (strings, hashes, lists, sets, sorted sets, streams, JSON, arrays, vector sets), a workbench with a Monaco-based query editor, CLI, pub/sub, slow log, profiler, database analysis with optimization recommendations, cloud integration (Redis Cloud, Azure Cache, Redis Enterprise), Redis Data Integration (RDI) pipeline management, and an AI assistant. The architecture is modular with clear separation of concerns, using repository and strategy patterns extensively. The codebase includes comprehensive CI/CD, end-to-end Playwright tests, and a plugin system for custom visualizations.
The Nu Html Checker (vnu) is a production-grade, multi-format web standards validator that checks HTML, CSS, SVG, and other document types for conformance to W3C specifications. It operates as a Java library, command-line tool, HTTP server (servlet), or Docker container. The codebase integrates several independently developed modules: an HTML5 parser (based on Mozilla's parser), a CSS validation engine (W3C CSS Validator), a RELAX NG schema validator (jing-trang), a URL canonicalization library (galimatias), and a language detection component. Validation is driven by a combination of RELAX NG schemas, DTDs, XSD datatypes, and hardcoded CSS property rules. The system is actively maintained and widely used, with a strong focus on correctness and standards compliance. Its architecture is modular but tightly coupled internally, reflecting its evolution from multiple W3C projects.
OpenAPI Generator CLI is a Node.js/TypeScript command-line wrapper around the Java-based OpenAPITools/openapi-generator JAR. Despite using NestJS, it is not a server: NestJS provides a DI application context that wires a Commander CLI. On every invocation (main.ts → AppModule.onApplicationBootstrap), it reads openapitools.json, resolves a generator version (querying Sonatype's Solr search for the latest stable when unset), writes it back to config, downloads and caches the JAR — atomically, via temp file + rename — then asks the Java CLI itself (via `help` and `completion` output) what commands it exposes, registers them dynamically, and spawns `java -jar ... <command>` with inherited stdio. It supports HTTP(S) proxies, JAVA_OPTS, custom generator JARs (classpath merge), and a Docker execution mode. Beyond pass-through, the CLI adds value the raw Java tool lacks: a `version-manager` subcommand (list/set/remove tagged versions backed by an interactive table picker) and a config-driven batch generator in openapitools.json where named generators map glob patterns to invocations with placeholder tokens (#{name}, #{cwd}, #{relPath}, #{ext}, ...), executed concurrently (max 10 processes). The repo is an Nx single-app monorepo bundled into a shebang'd main.js and released via semantic-release; GitHub Actions CI runs lint, unit tests, and real Java-based E2E on Ubuntu and macOS. Unit test coverage is thorough across config, version management, command pass-through, and command construction. Genuinely clever parts: dynamic discovery of an external CLI's command surface, atomic binary caching, and a table-to-interactive-select UI. The warts: a ~100-entry hardcoded fallback version list embedded in source, a legacy root lib/index.js publishing script superseded by the webpack package plugin, leftover NestJS scaffolding (environment stubs, 'not a production server' comment), deprecated RxJS toPromise() usage, an ESLint root config that effectively ignores all files, and a Nix flake pinned to Node 18 while the package requires Node 22. It does what it claims and is actively maintained, but the residue keeps it from being exemplary.
Ember Inspector is a browser extension (Chrome, Firefox, Opera, bookmarklet) that provides a rich debugging interface for Ember.js applications. It injects the `ember-debug` library into the target page, which collects runtime information about components, routes, data (Ember Data), promises, render performance, deprecations, and object internals. The inspector UI is an Ember.js application that communicates with the injected debug library via a message-passing port abstraction, using adapters specific to each browser environment. The codebase is a monorepo with four packages: `ember-debug` (injected debug library), `ember-inspector` (UI), and two test apps (classic and vite). It is actively maintained by the Ember core team, with CI/CD pipelines, extensive tests, and automated release planning. Architecture: The system is split into two halves. The `ember-debug` package uses a `Port` class for event-driven messaging and adapters (Chrome, Firefox, WebSocket, bookmarklet) to bridge the injected script to the extension's background page or devtools panel. The `ember-inspector` package is a full Ember app that renders tabs (Component Tree, Route Tree, Data, Promises, Deprecations, Render Performance, Info) and features an Object Inspector for drilling into property values and editing them. The UI uses a schema-based list rendering pattern, debounced search, and resizable/draggable columns. The object inspector handles both classic Ember objects and modern Glimmer components, including computed properties, tracked properties, getters, and services. Despite reliance on private Ember APIs and version-specific code paths, the codebase demonstrates strong engineering practices, with modular components that are potentially reusable (e.g., port messaging, adapter pattern, resizable columns, property display component).
Hippy is a cross-platform mobile application framework developed by Tencent that enables developers to build native mobile apps using JavaScript with React or Vue. It provides a JS driver layer that communicates with native renderers on Android, iOS, OpenHarmony, and Web via a bridge system. The architecture is modular: a DOM layer manages the virtual tree and layout (using Taitank or Yoga), native renderers create platform-specific UI components, and a virtual file system (VFS) handles resource loading. The framework includes a full devtools backend implementing Chrome DevTools Protocol for debugging, performance monitoring, and DOM inspection. Key entry points include the JS bootstrap (hippy.js), native engine managers (HippyEngine on Android, HippyBridge on iOS), and the JS framework adapters (hippy-react, hippy-vue, hippy-vue-next). External dependencies include V8, Hermes, JSC, or JSH JavaScript engines, and platform-specific SDKs (AndroidX, UIKit, ArkUI). The codebase is large and actively maintained, with multiple renderer implementations and both Vue 2 and Vue 3 support, though some duplication and deprecated code exist.
envio is a Rust CLI tool for managing environment variables in encrypted profiles. It creates, edits, imports, exports, and deletes profiles stored as `.envio` files in a project's `.envio/profiles` directory. The profiles can be plaintext or encrypted using passphrase (Argon2id + XChaCha20Poly1305), symmetric key (base64-encoded 32-byte key + XChaCha20Poly1305), or GPG (delegates to the system `gpg` CLI). The tool integrates with the OS keyring to store encryption keys and provides both a command-line interface and a TUI (beta) built with ratatui. The architecture cleanly separates library code (profile, cipher, env map) from binary code (CLI, TUI, prompts). The library is reusable for other Rust projects needing profile-based encrypted env management, though cipher types are somewhat coupled to the crate's error types. The encryption implementations demonstrate solid security practices (Argon2id password hashing, XChaCha20Poly1305 AEAD with streaming). The CI/CD pipeline builds for multiple platforms and generates shell completions and man pages at compile time. The project lacks unit tests in the visible source tree, which is a notable gap.
This repository is a monorepo for `react-router-devtools`, a Vite plugin that provides a comprehensive debugging and inspection UI for React Router v7+ applications. It integrates with TanStack DevTools to offer tabs for active page, routes, network waterfall, timeline, settings, errors, and custom plugins. The core mechanism uses Babel-based AST transformations to instrument server and client data functions (loaders, actions) with timing, tracing, and context wrappers without requiring user code changes. The package exports multiple entry points for client, server, and context integration, and supports both framework mode (Vite plugin) and declarative mode (EmbeddedDevTools component). The repository also includes a full documentation site built with React Router, example plugins (icon-library, tailwind-palette), and several test applications. It is a well-crafted developer tool with a modular architecture, but has some technical drift due to tight coupling to React Router internals and reliance on Babel AST transforms that may break with ecosystem changes.
OpenHPC is a community-driven software distribution and infrastructure framework for High Performance Computing (HPC) clusters. It provides a collection of RPM packages, installation recipes, and testing infrastructure to deploy and manage HPC environments on Linux distributions such as RHEL, SUSE, and openEuler. The repository serves as the build system and validation suite for the distribution, ensuring compatibility across multiple MPI implementations, compilers, and scientific libraries. It does not function as a single application but rather as a meta-package and deployment framework for HPC systems.
Speedlify is a web application for continuous performance monitoring of websites. It uses Eleventy as a static site generator to display historical Lighthouse scores, Core Web Vitals, and page weight metrics for specified URLs. The system runs automated tests via the performance-leaderboard package (which wraps Lighthouse/Puppeteer), stores results as JSON files, and generates trend visualizations using sparklines and charts. Key architectural elements include: data configuration in _data/sites/, test execution in run-tests.js, result storage in _data/results/, and Eleventy templates for presentation. The application is designed for Netlify deployment with caching to preserve test results between builds.
npkill is a TypeScript CLI/TUI application that scans filesystems to find node_modules (and other ecosystem build/dependency directories) consuming disk space, then interactively or programmatically deletes them. The core engine (Npkill class) exposes RxJS observable streams for scanning, size calculation, newest-file detection, deletion, and logging, with a worker_threads-based parallel directory traversal. The CLI layer adds a raw-mode interactive terminal UI with cursor navigation, multi-select deletion, search filtering, JSON/NDJSON output modes, --dry-run, .npkillrc config file support, and user-defined profiles. It ships both as a bin executable and as a programmatic Node library per API.md.
This is a Vue 3 Single-Page Application (SPA) that provides an interactive form-based interface for generating Markdown badges using the shields.io service. The application allows users to generate repo metadata badges, generic static badges, package version badges, dynamic data badges, image markdown/HTML, and a catalogue of pre-made badges. The code is written in TypeScript with a clean separation of concerns: core logic modules handle badge generation and URL construction, Vue components manage UI, and a simple store persists user preferences via localStorage. The architecture is monolithic with client-side routing via Vue Router. The project demonstrates solid software engineering practices with comprehensive unit tests, a Makefile for common tasks, and GitHub Actions CI/CD for linting, testing, and deployment. While the codebase is well-structured and maintainable, it relies on the deprecated Vue CLI and some packages are several major versions behind (e.g., TypeScript 4.6, ESLint 8), indicating moderate technical drift. The application is actively maintained with recent commits and a clear release process.
ttab is a single-file Bash CLI that programmatically opens new terminal tabs and windows on macOS (Terminal.app and iTerm2) and Linux (gnome-terminal). It supports running startup commands in the new tab, setting working directory, title, and profile, creating iTerm2 horizontal/vertical splits (-v/-h), creating tabs without stealing focus (-g/-G), delaying command submission (-l), and clearing the screen (-q). The entire application is bin/ttab: a ~700-line Bash script with zero runtime dependencies that parses options via getopts, detects the calling terminal through TERM_PROGRAM / GNOME_TERMINAL_SCREEN or an explicit -a flag, synthesizes backend-specific automation (AppleScript for Terminal.app and iTerm2, with distinct v2/v3 syntax paths, and a CLI argument string for gnome-terminal), and executes it via 'exec osascript' on macOS or eval on Linux. It embeds its full Markdown man page as a here-doc extracted by sed, so --help, --man, and --man-source all work from the single distributed file.