# My Opinionated ESLint Setup for Vue Projects



Over the last 7+ years as a Vue developer, I've developed a highly opinionated style for writing Vue components. Some of these rules might not be useful for you, but I thought it was worth sharing so you can pick what fits your project. The goal is to enforce code structure that's readable for both developers and AI agents.

These rules aren't arbitrary—they encode patterns I've written about extensively:

- <InternalLink slug="how-to-write-clean-vue-components">How to Write Clean Vue Components</InternalLink> explains why I separate business logic into pure functions
- <InternalLink slug="how-to-structure-vue-projects">How to Structure Vue Projects</InternalLink> covers my feature-based architecture approach
- <InternalLink slug="nuxt-layers-modular-monolith">Building a Modular Monolith with Nuxt Layers</InternalLink> applies feature isolation to Nuxt projects
- <InternalLink slug="the-problem-with-as-in-typescript-why-its-a-shortcut-we-should-avoid">The Problem with `as` in TypeScript</InternalLink> covers why I ban type assertions
- <InternalLink slug="robust-error-handling-in-typescript-a-journey-from-naive-to-rust-inspired-solutions">Robust Error Handling in TypeScript</InternalLink> introduces the Result pattern behind my `tryCatch` rule
- <InternalLink slug="vue3_testing_pyramid_vitest_browser_mode">Vue 3 Testing Pyramid</InternalLink> explains my integration-first testing strategy
- <InternalLink slug="frontend-testing-guide-10-essential-rules">Frontend Testing Guide</InternalLink> shares my test naming conventions

ESLint rules are how I enforce these patterns automatically—so the codebase stays consistent even as the team grows.

<Alert type="note">
**Why linting matters more in the AI era:** As AI agents write more of our code, strict linting becomes essential. It's a form of [back pressure](https://banay.me/dont-waste-your-backpressure/?ref=ghuntley.com)—automated feedback mechanisms that tell an agent when it's made a mistake, allowing it to self-correct without your intervention. You have a limited budget of feedback (your time and attention). If you spend that budget telling the agent "you missed an import" or "that type is wrong," you can't spend it on architectural decisions or complex logic. Type checkers, linters, and test suites act as back pressure: they push back against bad code so you don't have to. Your ESLint config is now part of your prompt—it's the automated quality gate that lets agents iterate until they pass.
</Alert>

## Table of Contents

## Why Two Linters? Oxlint + ESLint

I run two linters: **Oxlint** first, then **ESLint**. Why? Speed and coverage.

### Oxlint: The Speed Demon

[Oxlint](https://oxc.rs/docs/guide/usage/linter.html) is written in Rust. It runs 50-100x faster than ESLint on large codebases. My pre-commit hook completes in milliseconds instead of seconds.

```bash