$ show fwouts/previewjs
Preview.js is a developer tool for live component previews integrated into IDEs (VS Code, IntelliJ) and available as a CLI. It analyzes source code to detect UI components and Storybook stories, extracts their props via a custom TypeScript type analyzer, and renders them in an isolated iframe powered by Vite with Hot Module Replacement. The system consists of a core server library (`@previewjs/core`), framework-specific plugins (React, Preact, Solid, Svelte, Vue 2/3), a virtual file system abstraction, and a type analysis engine. It targets frontend developers who want instant visual feedback on component changes without leaving their editor. The project is explicitly **no longer maintained** per the README, and the codebase shows signs of technical drift with outdated test apps and potential dependency stagnation. Despite its abandonment, the architecture is well-structured: a monorepo with clear separation of concerns (loader/worker pattern for isolate Vite servers, iframe controller, screenshot generator, serializable value handling). The type analyzer and virtual filesystem are reusable components that demonstrate non-obvious skill with TypeScript compiler API and abstract file access patterns.
The LLM identified 2 files worth highlighting for reuse:
Provides `TypeAnalyzer` and `TypeResolver` classes that walk TypeScript AST to extract component prop types into a portable `ValueType` representation (objects, unions, arrays, functions, generics, etc.). It handles special types like `Component` and `Promise`, resolves type parameters, and supports arbitrary type aliases. This is a self-contained, reusable library that could be extracted for any project needing deep TypeScript type introspection, demonstrating advanced use of the TypeScript compiler API.
Implements `StackedReader` that layers multiple `Reader` instances (e.g., memory, real filesystem) to provide a unified file interface with fallback order. It is a clean abstraction for virtualizing file access, useful in environments where file changes need to be overlaid (e.g., in-memory edits on top of a real project). The pattern is reusable across build tools, testing frameworks, and any context needing layered file access without coupling to a specific storage backend.