Nuxt 4 Starter Kit Your Launchpad for Modern Web Development
Nuxt 4
Starter Kit
Quality Assurance
By Oxlint, Vitest, Husky ...
Styling
Sass & Tailwind
Accelerate Your Development Workflow with Pre-Configured Tools and Best Practices
Launching a modern web application in 2025 demands more than just writing code—it requires a carefully orchestrated ecosystem of build tools, linters, formatters, testing frameworks, and styling systems working in harmony.
The Nuxt 4 Starter Kit addresses this challenge head-on, providing a batteries-included foundation that eliminates configuration overhead and lets you focus on what truly matters: building exceptional user experiences.
By combining Nuxt 4's latest architectural improvements with industry-standard tools like Vite, TypeScript, Vitest, and Tailwind CSS, this starter kit delivers both organizational efficiency and technical excellence.
Why Another Starter Kit
Evaluating development infrastructure, the choice of starting point fundamentally shapes project velocity, code quality, and long-term maintenance costs. Traditional greenfield development—where teams configure every tool from scratch—can consume a lot of initial project time before a single feature ships.
Nuxt 4 Starter Kit By Lazercaveman (Ali Soueidan)There are, of course, numerous Nuxt starter kits out there—while many exist, this one was specifically developed to meet my personal standard often missing in alternatives, integrating and pre-configuring packages essential for immediate project readiness. I integrated and configured all the packages that I considered essential so that I could get started on new projects right away.
The Nuxt 4 Starter Kit specifically targets this opportunity, combining Nuxt's latest stability-focused release with a curated toolchain designed for professional software development—and I also added comments explaining the setup, why it is done the way it is, and a clean-up script, which I will also discuss in detail in this blog post.
Want to Try the Nuxt Starter Kit?
Head over to the repository to download the template, explore the code, or contribute your own improvements.
For developers evaluating the technical merits, the Nuxt 4 Starter Kit distinguishes itself through architectural decisions that prioritize performance, developer experience, and maintainability. Let's examine each component systematically.
Nuxt 4: Evolution, Not Revolution
Nuxt 4, released in July 2025, represents a maturation of the Vue.js meta-framework rather than a disruptive rewrite. The most significant architectural change introduces the optional app/ directory structure, which provides cleaner separation between application code and infrastructure files.
This structure delivers practical benefits for file watchers, particularly on Windows and Linux systems where scanning fewer directories improves hot module replacement (HMR) performance. IDEs gain clearer context about whether code executes client-side or server-side, enhancing autocomplete accuracy and refactoring tools.
Vite: Speed at Development and Build Time
Vite's inclusion represents a non-negotiable performance choice. Traditional bundlers like Webpack process entire applications before starting development servers, creating multi-second startup delays that compound across development sessions. Vite's architecture inverts this model: it serves unbundled ES modules during development and compiles dependencies on-demand using esbuild, a Go-based compiler that operates 10–100x faster than JavaScript alternatives.
Performance benchmarks demonstrate the practical impact. Testing on a medium-sized Vue application showed development server startup dropping from 5,551ms (Webpack) to 345ms (Vite)—a 16x improvement. Production builds accelerated from 6,244ms to 4,500ms. Hot module replacement (HMR) operates in microseconds for cached modules, creating an instantaneous feedback loop during iterative development.
The Nuxt 4 Starter Kit leverages Vite's native integration with Nuxt, requiring zero additional configuration. As you develop, Vite's HMR preserves application state between updates—modifying a component's styling doesn't reset form inputs or navigation state, maintaining development flow. For production, Vite switches to Rollup for bundling, employing tree-shaking and code-splitting to minimize delivered JavaScript.
Oxlint: High-Performance Linting Built on Rust
ESLint served the JavaScript ecosystem well for over a decade. But as projects grow, its JavaScript-based architecture becomes a visible bottleneck—particularly in CI pipelines and large monorepos where linting can consume tens of seconds. The Starter Kit replaces ESLint entirely with oxlint, a Rust-based linter from the Oxc compiler toolchain.
The performance difference is not incremental. Oxlint is 50–100x faster than ESLint depending on the codebase size and available CPU cores. On a medium-sized TypeScript project, ESLint might take 30+ seconds on a cold run; oxlint finishes the same job in under a second. This speed comes from Rust's zero-overhead abstractions, multi-threaded file processing, and a shared parser that avoids the repeated parsing overhead inherent in ESLint's plugin architecture.
Oxlint ships with 700+ built-in rules, covering many widely used ESLint ecosystems such as import, unicorn, vitest, and Vue. These rules are implemented natively, so in most cases no additional plugin installation is required and execution remains fast. By default, Oxlint focuses on high-signal correctness checks—code that is incorrect, unsafe, or redundant—rather than stylistic concerns. The ruleset can be expanded incrementally as project requirements evolve. Support for type-aware TypeScript rules is available via oxlint-tsgolint, which provides coverage for most typescript-eslint checks.
The decision to fully remove ESLint—rather than running both tools in tandem—reflects a deliberate choice for simplicity. Maintaining two linters introduces configuration drift, duplicate diagnostics, and cognitive overhead that undermines the Starter Kit's goal of immediate productivity.
Oxfmt: Dedicated Formatting, Separated by Design
Formatting is no longer handled by the linter. The Starter Kit introduces oxfmt, also from the Oxc toolchain, as a dedicated code formatter. This separation of concerns is intentional: a linter checks for logic and correctness, while a formatter enforces code style. Conflating the two—as ESLint with stylistic rules or Prettier integration often does—creates unnecessary coupling and slower execution.
Oxfmt is a Rust-powered, Prettier-compatible formatter. Benchmarks show it running approximately 30x faster than Prettier and around 3x faster than Biome on initial runs without caching. It supports JavaScript, JSX, TypeScript, TSX, Vue single-file components, JSON, CSS, SCSS, Markdown, and many other formats—meaning a single formatter handles the entire project.
Key features relevant to the Starter Kit include built-in Tailwind CSS class sorting (no separate Prettier plugin required), automatic import sorting, and package.json field sorting. Oxfmt passes 100% of Prettier's JavaScript and TypeScript conformance tests, so migration from Prettier-based workflows is straightforward with minimal formatting differences.
Configuration is handled through a simple .oxfmtrc.json or oxfmt.config.ts file. The Starter Kit includes sensible defaults. If your team previously used Prettier, the CLI conventions are similar enough that most scripts require little or no modification.
By pairing oxlint for correctness with oxfmt for style, the Starter Kit achieves a clean separation of concerns: each tool does one job, does it fast, and stays out of the other's way.
Testing infrastructure often becomes a bottleneck in large projects where test suites run for minutes, creating friction in continuous integration pipelines. Vitest addresses this through architectural alignment with Vite: it reuses Vite's transformation pipeline and esbuild for transpilation, achieving 3–4x faster test execution compared to Jest.
Practical performance comparison from production applications illustrates the magnitude. Running 500 tests with Vitest completes in ~3 seconds versus ~8 seconds with Jest—a 160% speed improvement. Watch mode exemplifies Vitest's efficiency: when you modify a single file, Vitest re-runs only affected tests, with incremental execution measured in milliseconds. This tight feedback loop fundamentally changes testing behavior—developers run tests continuously rather than as infrequent batch operations.
The Starter Kit configures Vitest with coverage tracking via v8, Nuxt's recommended provider. V8 coverage instruments code at the JavaScript engine level, avoiding pre-transpilation overhead and delivering coverage reports comparable in accuracy to Istanbul. The @vitest/ui package provides browser-based test visualization.
Coverage metrics integrate directly into the Vitest UI, displaying line, branch, and function coverage alongside test results. When tests fail, the UI includes one-click navigation to the relevant source file in VS Code, reducing debugging friction.
Husky: Enforcing Quality at Git Boundaries
Automated quality gates prevent issues from entering shared branches, reducing code review overhead and CI/CD failures. Husky implements this through Git hooks—scripts that execute at specific Git lifecycle points. The Starter Kit configures a pre-push hook that runs linting and tests before allowing pushes to remote repositories.
This approach creates a forcing function for quality. Developers cannot push code that violates linting rules or breaks existing tests, ensuring the main branch maintains a baseline quality standard. The implementation weighs only 2KB gzipped and executes in ~1ms, adding negligible overhead to Git operations.
Operational considerations: Pre-push hooks can frustrate developers if execution time grows excessive (>30 seconds). The Starter Kit mitigates this by running only essential checks—linting via oxlint and tests via Vitest—both optimized for speed. Oxlint's sub-second execution means the linting step adds virtually no delay to the push workflow, a marked improvement over the ESLint-based setup. For repositories with extensive test suites, teams might configure pre-push hooks to run only affected tests or defer comprehensive testing to CI/CD pipelines.
Tailwind CSS: Utility-First Styling at Scale
Tailwind CSS represents a departure from traditional CSS methodologies like BEM or SMACSS, instead providing low-level utility classes that compose into complex designs. The Starter Kit includes Tailwind CSS v4, which introduces a high-performance engine and native Vite integration.
Performance characteristics distinguish Tailwind v4. Full builds complete 3.78x faster than v3, while incremental rebuilds (no new CSS) execute in 192 microseconds—over 100x faster. This speed stems from architectural changes: Tailwind v4 leverages native CSS cascade layers, registered custom properties via @property, and color-mix() for opacity adjustments, offloading work to the browser's rendering engine.
The utility-first approach delivers development velocity advantages. Consider styling a responsive card component:
All styling occurs inline via utility classes, requiring no separate CSS files. Tailwind's PurgeCSS integration removes unused classes during production builds, keeping final CSS bundles minimal regardless of how many utilities exist in the framework.
Critical perspective: Tailwind's utility-first approach attracts both advocates and critics. Proponents cite rapid prototyping, design consistency, and reduced context-switching between HTML and CSS. Critics note that heavy utility usage can create verbose HTML and make complex component styling difficult to parse. The Starter Kit acknowledges both perspectives by including SASS alongside Tailwind, enabling developers to use utilities for most styling while falling back to SCSS for animations or complex selectors when appropriate.
SASS: Flexibility for Advanced Styling
While Tailwind handles the majority of styling needs, certain scenarios benefit from SCSS's programming features—variables, mixins, nesting, and functions. The Starter Kit includes SASS with explicit guidance: avoid using @apply to compose Tailwind utilities within SCSS files, as this creates an abstraction layer that undermines Tailwind's utility-first philosophy. Appropriate SCSS use cases include:
Complex animations that require keyframe definitions and timing functions
Custom calculations using SCSS functions for responsive sizing
Third-party component styling where utility classes aren't accessible
Legacy code integration when migrating existing SCSS codebases
This SCSS augments Tailwind rather than replacing it, maintaining the utility-first approach while accessing CSS features that lack utility equivalents.
Pinia: Modern State Management
State management complexity scales non-linearly with application size—ad hoc solutions work for small apps but become unmaintainable as components multiply and share data. Pinia, Vue's official state management library, addresses this through a lightweight API that integrates seamlessly with Vue 3's Composition API.
Architectural advantages over Vuex (Pinia's predecessor) include simpler APIs, full TypeScript support, and better integration with Vue DevTools. Pinia's 1KB bundle size ensures it adds negligible overhead to application bundles. For SSR scenarios (Nuxt's default), Pinia provides automatic per-request state isolation, preventing data leakage between concurrent users—a critical consideration for server-rendered applications.
TypeScript: Type Safety as Development Infrastructure
JavaScript's dynamic typing enables rapid prototyping but creates maintenance challenges at scale. TypeScript addresses this by adding optional static types, catching errors during development rather than at runtime. The Starter Kit configures TypeScript with strict mode enabled, enforcing type safety across the codebase.
Concrete benefits manifest in multiple dimensions. IDE integration provides real-time error checking and intelligent autocomplete—hovering over variables displays their types, method calls show parameter signatures, and refactoring operations propagate consistently. For Nuxt applications specifically, TypeScript integration enhances auto-imports and component props validation. Nuxt automatically generates type definitions for routes, making navigation type-safe.
Migration considerations: Adding TypeScript to existing JavaScript projects requires incremental adoption. The Starter Kit's configuration supports gradual migration—JavaScript files coexist with TypeScript, allowing teams to convert modules progressively rather than attempting comprehensive rewrites.
Vite-SVG-Loader: Component-Based Icon Management
Modern web applications frequently incorporate SVG icons for scalability and styling flexibility. The Starter Kit includes vite-svg-loader, which imports SVG files as Vue components, enabling dynamic styling and reducing HTTP requests. The loader optimizes SVGs via SVGO, removing unnecessary metadata and reducing file sizes.
Color styling uses currentColor, allowing icons to inherit text color from parent elements—a crucial feature for maintaining design consistency across themes. This pattern centralizes icon management and enables lazy loading—icons load only when components render.
Structured Context for AI-Assisted Development
As AI-assisted development tools like Claude Code become part of professional workflows, a recurring challenge emerges: these tools start every session without knowledge of your project's conventions, architecture, or tooling decisions. Developers end up repeating the same context—directory structure, coding standards, preferred commands—at the start of every interaction.
The Starter Kit addresses this by including a claude-code.md file in the project root. This file provides structured, machine-readable context that AI coding agents consume automatically at the beginning of each session. Rather than treating AI tooling as an afterthought, the Starter Kit acknowledges it as part of the modern development workflow and configures it from the start.
The claude-code.md file in the Starter Kit typically covers:
Project architecture: The Nuxt 4 directory structure, the role of the app/ directory, and how files are organized.
Tooling and commands: Which package manager to use, how to run tests, how to lint, and how to format—so the AI agent invokes the correct tools (oxlint and oxfmt, not ESLint or Prettier).
Coding conventions: TypeScript strict mode, component naming patterns, and style guidelines specific to the project.
Boundaries: What the AI should and should not modify—for example, not altering configuration files without explicit instruction.
The practical benefit is consistency. When an AI agent understands that the project uses oxlint for linting and oxfmt for formatting, it won't generate ESLint configurations or Prettier scripts. When it knows the app/ directory structure, it places new components in the correct location. This reduces back-and-forth correction and keeps AI-generated code aligned with the project's existing patterns.
Including claude-code.md as part of the Starter Kit means new projects begin with this context already defined. Developers can refine it as the project evolves, but the foundation is there from the first commit.
The Cleanup Script: From Template to Custom Foundation
The Nuxt 4 Starter Kit inevitably includes demonstration content—example components, test fixtures, and placeholder assets, helpful comments and so on. The Nuxt 4 Starter Kit addresses this through an automated cleanup script that removes demo content while preserving directory structure.
Running yarn script:cleanup executes this process, transforming the starter kit into a clean slate in seconds. Critical detail: The script deletes the .git folder, disconnecting your project from the starter kit's Git history. Initialize a new repository afterward to establish your project's version control.
MIT License: Commercial Freedom and Flexibility
The Starter Kit's MIT License provides unrestricted commercial usage rights—you can build proprietary applications, sell software, or integrate components into closed-source products without attribution requirements beyond preserving the original license notice.
Organizational implications prove significant. Unlike copyleft licenses (GPL, AGPL) that require derivative works to remain open source, MIT imposes minimal restrictions. This permissiveness enables:
Commercial product development without source code disclosure obligations
Proprietary modifications that remain private
Integration with existing codebases regardless of their licensing
Redistribution with or without modifications
Practical Implementation: Getting Started
Setting up a project from the Nuxt 4 Starter Kit requires three steps:
1.
Clone or download the repository
2.
Install dependencies using the specified Node.js and Yarn versions
3.
Start development or run the cleanup script
The engines field in package.json pins the exact Node.js version, ensuring consistent builds across team members and CI/CD environments. With engineStrict: true, yarn will refuse to install with an unsupported version, so every team member is on the same page.
Dependency management: The Starter Kit uses Yarn v4.9.1 (specified in package.json). If you prefer npm or pnpm, dependency installation works identically—package managers interoperate for installation despite different lock file formats.
Summary and Recommendations
By pre-integrating Vite, oxlint, oxfmt, Vitest, Tailwind, TypeScript, and a claude.md for AI-assisted workflows with sensible defaults, the Nuxt 4 Starter Kit reduces setup time to a single command. That means less time debugging build configurations and more time solving interesting problems. The MIT License ensures commercial viability without restrictive obligations.
The shift from ESLint to oxlint and oxfmt reflects a broader trend in the JavaScript ecosystem: Rust-based tooling that delivers orders-of-magnitude performance improvements without sacrificing the rule coverage developers depend on. Separating linting from formatting clarifies each tool's responsibility and eliminates the configuration tangles that ESLint-plus-Prettier setups often create.
The web development landscape will continue evolving—new frameworks, build tools, and patterns emerge constantly. Starter kits like this one provide stability amidst that change, offering proven configurations that let you focus on building rather than assembling. Whether you're launching your first Nuxt project or your fiftieth, having a reliable starting point eliminates friction and accelerates delivery.
No technical solution applies universally. The Nuxt 4 Starter Kit optimizes for specific scenarios while potentially mismatching others—the key evaluation criterion: does the Starter Kit's configuration align with your technical requirements, or does customization effort exceed building from scratch?
If you have any questions, don't hesitate to reach out—leave a message, issue, or feature request on GitHub or reach out directly by mail.
A Senior Freelance Web Developer based in Cologne/Bonn region, and every now and then I enjoy writing articles like this one to share my thoughts ... : )
