TinyPort
Import weight analysis for JavaScript and TypeScript: the real bundled and gzipped bytes, shipped as a CLI, a VS Code extension, and an MCP server from one engine.
TypeScript · Node.js · esbuild · MCP · VS Code
Nobody knows what an import actually costs. The number most tools show is the package's size on disk, which is not what a bundler ships. The whole next package is 212 MB; next/link is 48.6 kB bundled and 15.2 kB gzipped. So bundle bloat gets discovered after it ships.
TinyPort measures the real bytes instead of guessing. It resolves each import's entry, bundles and tree-shakes it with esbuild taken from your project rather than its own, then gzips the result. Every figure in the output is labelled bundled or shipped, so a measurement is never mistaken for an estimate.
Live on four surfaces from a single core engine: tinyport.vantaso.org, the tinyport CLI and @tinyport/mcp on npm, and the TinyPort extension on the VS Code Marketplace. MIT licensed.
Key Features
- —Real bundled and gzipped size per import, tree-shaken: a named import from lucide-react measures the one icon it pulls in (about 12 kB), not the megabyte of every icon in the package
- —tinyport check fails the build the moment a file goes over its byte budget, so budgets actually hold in CI
- —Imports sorted heaviest-first and grouped by origin, with the diff shown first and nothing written until you ask for it
- —Unused imports are flagged, never removed. Deletion stays the developer's call
- —Inline per-import sizes in VS Code the moment a file opens, and sort-on-save that backs off when another formatter is already running
- —esbuild is resolved from the project under analysis, not from TinyPort, and falls back to a labelled disk estimate whenever it is unavailable
The MCP Server
@tinyport/mcp gives an AI coding agent six tools (analyze_file, scan_project, check_budget, suggest_alternatives, explain_package, and apply_fixes) so it can ask what a package costs before it ever adds it. The interface is built so an autonomous agent cannot do damage by accident: apply_fixes is dry-run by default and only accepts fix ids the analysis step actually produced, so an agent cannot invent an edit, and nothing in your project is written unless it is explicitly told to.