# Code Style and Conventions Standards for Vite

This document outlines the coding style and conventions to follow when developing with Vite. Adhering to these standards will improve code readability, maintainability, and consistency across projects. These guidelines are designed to be compatible with AI coding assistants such as GitHub Copilot and Cursor.

## 1. General Principles

### 1.1. Consistency

* **Do This:** Maintain a consistent style throughout the codebase. Use tools like Prettier and ESLint to enforce these standards automatically.

* **Don't Do This:** Mix different coding styles within the same project, as this reduces readability and increases cognitive load.

* **Why:** Consistency is key to making code easier to understand and maintain. A predictable style allows developers to quickly grasp the structure and intent of the code.

### 1.2. Readability

* **Do This:** Write code that is easy to read and understand. Use meaningful variable names, clear comments, and proper indentation.

* **Don't Do This:** Write overly complex or convoluted code that is difficult to decipher.

* **Why:** Readability is crucial for collaboration and long-term maintainability. Code should be self-explanatory and easy for others (and your future self) to understand.

### 1.3. Simplicity

* **Do This:** Keep code simple and focused. Break down complex tasks into smaller, manageable functions or modules.

* **Don't Do This:** Write large, monolithic functions or modules that are hard to test and maintain.

* **Why:** Simpler code is easier to understand, test, and debug. It reduces the risk of introducing bugs and makes it easier to refactor when necessary.

## 2. Formatting

### 2.1. Indentation

* **Do This:** Use 2 spaces for indentation.

* **Don't Do This:** Use tabs or a combination of tabs and spaces.

* **Why:** Two spaces provide a good balance between readability and code density.

"""javascript

// Correct indentation

function myFunction() {

console.log('Hello, world!');

}

// Incorrect indentation

function myFunction() {

console.log('Hello, world!');

}

"""

### 2.2. Line Length

* **Do This:** Limit lines to a maximum of 120 characters.

* **Don't Do This:** Exceed the recommended line length.

* **Why:** Shorter lines are easier to read and prevent horizontal scrolling.

### 2.3. Whitespace

* **Do This:** Use whitespace to improve readability, including:

* A blank line after each function or method.

* Spaces around operators (=, +, -, *, /, etc.).

* Spaces after commas in lists.

* **Don't Do This:** Omit whitespace or use excessive whitespace.

* **Why:** Proper whitespace enhances readability by visually separating code elements.

"""javascript

// Correct usage of whitespace

function add(a, b) {

return a + b;

}

const result = add(1, 2);

console.log(result);

// Incorrect usage of whitespace

function add(a,b){

return a+b;

}

const result=add(1,2);

console.log( result );

"""

### 2.4. Semicolons

* **Do This:** Always use semicolons at the end of statements.

* **Don't Do This:** Rely on automatic semicolon insertion (ASI).

* **Why:** Using semicolons explicitly avoids unexpected behavior due to ASI and improves code predictability.

"""javascript

// Correct usage of semicolons

const message = 'Hello, world!';

console.log(message);

// Incorrect usage (relying on ASI)

const message = 'Hello, world!'

console.log(message)

"""

### 2.5. Trailing Commas

* **Do This:** Use trailing commas in object literals, arrays, and function parameters.

* **Don't Do This:** Omit trailing commas.

* **Why:** Trailing commas simplify adding, removing, or reordering elements. They also lead to cleaner diffs in version control.

"""javascript

// Correct usage of trailing commas

const person = {

firstName: 'John',

lastName: 'Doe',

};

const numbers = [

];

function greet(

name,

greeting,

) {

console.log("${greeting}, ${name}!");

}

// Incorrect usage

const person = {

firstName: 'John',

lastName: 'Doe'

};

"""

## 3. Naming Conventions

### 3.1. Variables

* **Do This:** Use descriptive, camelCase names.

* **Don't Do This:** Use single-letter names or cryptic abbreviations.

* **Why:** Clear variable names make code easier to understand.

"""javascript

// Correct variable names

const userFirstName = 'John';

const numberOfItems = 10;

// Incorrect variable names

const fn = 'John';

const noi = 10;

"""

### 3.2. Functions

* **Do This:** Use descriptive, camelCase names that clearly indicate the function's purpose.

* **Don't Do This:** Use ambiguous or overly short names.

* **Why:** Explicit function names improve code readability and maintainability.

"""javascript

// Correct function names

function calculateTotalAmount(price, quantity) {

return price * quantity;

}

// Incorrect function names

function calc(p, q) {

return p * q;

}

"""

### 3.3. Constants

* **Do This:** Use uppercase, snake_case names for constants.

* **Don't Do This:** Use lowercase or camelCase names for constants.

* **Why:** Uppercase names clearly indicate that the variable is a constant and should not be modified.

"""javascript

// Correct constant names

const MAX_USERS = 100;

const API_URL = 'https://example.com/api';

// Incorrect constant names

const maxUsers = 100;

const apiUrl = 'https://example.com/api';

"""

### 3.4. Components (Vue/React with Vite)

* **Do This:** Use PascalCase names for components. File names should match the component name.

* **Don't Do This:** Use kebab-case or camelCase names.

* **Why:** PascalCase is the standard convention for components in both Vue and React, enhancing consistency.

"""jsx

// Correct component name and file name (e.g., MyComponent.jsx)

function MyComponent() {

return My Component;

}

export default MyComponent;

// Incorrect component name

function myComponent() {

return My Component;

}

"""

### 3.5. File and Directory Structure

* **Do This:** Structure your project logically, separating concerns into different directories (e.g., "components", "utils", "api"). Use descriptive file names following the component or module naming conventions.

* **Don't Do This:** Dump all files into a single directory or use cryptic file names.

* **Why:** A well-organized file structure makes it easier to navigate and maintain the project.

"""

/src

├── components/

│ ├── MyComponent.jsx

│ ├── AnotherComponent.jsx

├── utils/

│ ├── api.js

│ ├── helpers.js

├── App.jsx

├── main.jsx

"""

## 4. Vite-Specific Conventions

### 4.1. Environment Variables

* **Do This:** Use ".env" files for environment variables and access them via "import.meta.env".

* **Don't Do This:** Hardcode sensitive information directly into the code.

* **Why:** Environment variables allow you to configure your application for different environments (e.g., development, production) without modifying the code.

"""javascript

// .env file

VITE_API_URL=https://api.example.com

// In your component or module

const apiUrl = import.meta.env.VITE_API_URL;

console.log(apiUrl);

"""

### 4.2. Asset Imports

* **Do This:** Import assets (images, fonts, etc.) directly using their relative paths. Vite handles these imports efficiently.

* **Don't Do This:** Use absolute paths or manual asset management.

* **Why:** Vite automatically optimizes and bundles imported assets, providing better performance and simplified asset management.

"""javascript

// Correct asset import

import logo from './assets/logo.svg';

function MyComponent() {

return ;

}

export default MyComponent;

"""

### 4.3. Dynamic Imports

* **Do This:** Use dynamic imports ("import()") for code splitting, especially for large components or modules that are not immediately needed.

* **Don't Do This:** Load all code upfront, which can slow down initial page load.

* **Why:** Dynamic imports allow you to load code on demand, improving performance by reducing the initial bundle size.

"""javascript

// Dynamic import

async function loadComponent() {

const { default: MyComponent } = await import('./components/MyComponent');

// Use MyComponent

}

loadComponent();

"""

### 4.4. Vite Plugins

* **Do This:** Utilize Vite plugins for common tasks like transforming code, optimizing assets, and integrating with other tools. Configure plugins in "vite.config.js".

* **Don't Do This:** Implement complex build processes manually when a plugin can handle it.

* **Why:** Vite plugins extend Vite's functionality and streamline the build process.

"""javascript

// vite.config.js

import { defineConfig } from 'vite';

import vue from '@vitejs/plugin-vue';

export default defineConfig({

plugins: [vue()],

});

"""

### 4.5. Development Server

* **Do This:** Leverage Vite's built-in development server for fast hot module replacement (HMR) during development. Take advantage of features like proxying API requests.

* **Don't Do This:** Use a separate development server that doesn't integrate with Vite's build pipeline.

* **Why:** Vite's development server provides a superior development experience with fast updates and seamless integration.

"""javascript

// vite.config.js (proxy example)

import { defineConfig } from 'vite';

export default defineConfig({

server: {

proxy: {

'/api': {

target: 'https://api.example.com',

changeOrigin: true,

rewrite: (path) => path.replace(/^\/api/, '')

}

});

"""

### 4.6. Build Configuration

* **Do This:** Configure the build process in "vite.config.js" to optimize the output for production. Use features like code minification, tree shaking, and asset inlining.

* **Don't Do This:** Use default build settings without considering production requirements.

* **Why:** Proper build configuration is essential for optimizing performance and reducing the size of the production bundle. Consider using the "defineConfig" helper for type safety.

"""javascript

// vite.config.js

import { defineConfig } from 'vite';

import { terser } from 'rollup-plugin-terser';

export default defineConfig({

build: {

minify: 'terser', // applies minification

rollupOptions: {

plugins: [terser()], // configures minification with terser

});

"""

### 4.7. Server-Side Rendering (SSR)

* **Do This:** If using SSR, structure your code to support both server and client environments. Use "process.server" (or equivalent with Vite SSR plugins) to conditionally execute server-specific code. Configure Vite for SSR builds.

* **Don't Do This:** Write code that only works on one environment.

* **Why:** Supporting both environments is crucial for SSR applications.

"""javascript

// Example of conditional code execution

if (import.meta.env.SSR) {

// Server-side code

console.log('Running on the server');

} else {

// Client-side code

console.log('Running on the client');

}

"""

### 4.8 Lazy Loading Images

* **Do This:** Implement Lazy Loading for images and other media to improve page load performance.

* **Don't Do This:** Load all assets upfront, especially for content below the fold.

* **Why:** Lazy loading improves initial load time by only loading visible assets.

"""html

"""

### 4.9 Minimize Third Party Libraries

* **Do This:** Evaluate and minimize usage of third party libraries, choosing the smallest and most efficient libraries when necessary.

* **Don't Do This:** Add numerous large libraries without considering their impact on performance.

* **Why:** Reduces bundle size and dependencies, leading to faster load times and improved security.

## 5. Stylistic Consistency

### 5.1. Quotes

* **Do This:** Use single quotes ("'") for strings, unless you need to embed variables.

* **Don't Do This:** Use double quotes (""") unnecessarily.

* **Why:** Single quotes are more common in JavaScript and can be slightly more efficient.

"""javascript

// Correct usage of single quotes

const message = 'Hello, world!';

// Use template literals for variable embedding

const name = 'John';

const greeting = "Hello, ${name}!";

"""

### 5.2. Object Literals

* **Do This:** Use concise syntax for object literals.

* **Don't Do This:** Use verbose syntax unnecessarily.

* **Why:** Concise syntax makes code cleaner and easier to read.

"""javascript

// Correct concise syntax

const person = {

firstName: 'John',

lastName: 'Doe',

};

// Incorrect verbose syntax

const person = {

firstName: person.firstName,

lastName: person.lastName

};

"""

### 5.3. Arrow Functions

* **Do This:** Use arrow functions ("=>") for concise, simple functions, especially when using higher-order functions like "map" and "filter".

* **Don't Do This:** Use arrow functions for complex functions with multiple statements; use traditional function declarations for those.

* **Why:** Arrow functions provide a more compact syntax and automatically bind "this" to the surrounding context, making them ideal for simple callbacks and expressions.

"""javascript

// Correct usage of arrow functions

const numbers = [1, 2, 3];

const squaredNumbers = numbers.map(number => number * number);

// Use traditional function declaration for complex functions

function calculateTotal(items) {

let total = 0;

for (const item of items) {

total += item.price * item.quantity;

}

return total;

}

"""

### 5.4. Ternary Operators

* **Do This:** Use ternary operators ("condition ? value1 : value2") for simple conditional assignments or expressions.

* **Don't Do This:** Use ternary operators for complex logic or multiple nested conditions.

* **Why:** Ternary operators provide a concise way to express simple conditional logic.

"""javascript

// Correct usage of ternary operator

const age = 20;

const isAdult = age >= 18 ? true : false;

// Avoid for complex logic

const result = (a > b) ? (a > c ? a : c) : (b > c ? b : c); // Hard to read!

"""

## 6. Error Handling

### 6.1. Try-Catch Blocks

* **Do This:** Use "try-catch" blocks to handle potential errors in asynchronous operations, like API calls or dynamic imports.

* **Don't Do This:** Ignore potential errors or rely solely on unhandled rejections.

* **Why:** Proper error handling prevents unexpected crashes and provides a better user experience.

"""javascript

// Correct error handling

async function fetchData() {

try {

const response = await fetch('https://example.com/api/data');

const data = await response.json();

return data;

} catch (error) {

console.error('Error fetching data:', error);

// Handle the error (e.g., display an error message to the user)

}

fetchData();

"""

### 6.2. Error Logging

* **Do This:** Log errors with sufficient context to help with debugging. Include relevant information like the component name, function name, and error message.

* **Don't Do This:** Log errors without any context, making it difficult to troubleshoot.

* **Why:** Detailed error logs are essential for diagnosing and fixing issues in production.

## 7. Comments and Documentation

### 7.1. Code Comments

* **Do This:** Write clear and concise comments to explain complex logic, non-obvious code, or important decisions.

* **Don't Do This:** Comment obvious code or write comments that are outdated or misleading.

* **Why:** Comments should provide additional context and help developers understand the "why" behind the code.

"""javascript

// This function calculates the total price of items in the cart

function calculateTotalPrice(cartItems) {

// ...

}

"""

### 7.2. JSDoc

* **Do This:** Use JSDoc syntax to document functions, classes, and modules.

* **Don't Do This:** Omit documentation for important parts of the codebase.

* **Why:** JSDoc-style comments enable tools to generate API documentation and provide better code completion and type checking.

"""javascript

/**

* Greets a person with a given name.

* @param {string} name - The name of the person to greet.

* @returns {string} A greeting message.

function greet(name) {

return "Hello, ${name}!";

}

"""

## 8. Security

### 8.1 Input Validation

* **Do This:** Validate all user inputs on both the client and server-side and sanitize potentially malicious data.

* **Don't Do This:** Trust the client-side data without validation.

* **Why:** Prevents XSS attacks, SQL injection, and other security vulnerabilities.

### 8.2 Avoid Hardcoding Sensitive Data

* **Do This:** Use environment variables to store any keys or tokens that should not be exposed.

* **Don't Do This:** Hard code API keys, passwords, or other sensitive information in the application code, risking exposure.

* **Why:** Keeps private credentials from being exposed in the code repository.

### 8.3 Dependency Management

* **Do This:** Regularly review and update project dependencies to patch security vulnerabilities as soon as they are released. Use tools like "npm audit" or "yarn audit".

* **Don't Do This:** Use outdated dependencies without security patches.

* **Why:** Prevents usage of compromised packages that may introduce security risks.

## 9. Continuous Integration/Continuous Deployment (CI/CD)

### 9.1. Automated Linting and Formatting

* **Do This:** Integrate linting and formatting tools (e.g., ESLint, Prettier) into your CI/CD pipeline to automatically enforce coding standards on every commit.

* **Don't Do This:** Rely solely on manual code reviews to catch style issues.

* **Why:** Automated linting and formatting ensures consistent code style across the entire team, reduces the burden on code reviewers, and minimizes the risk of style-related bugs.

### 9.2. Automated Testing

* **Do This:** Set up automated unit, integration, and end-to-end tests in your CI/CD pipeline to catch regressions and ensure code quality.

* **Don't Do This:** Skip automated testing or rely solely on manual testing.

* **Why:** Automated testing provides confidence in the codebase, accelerates development, and reduces the risk of introducing bugs into production.

## 10. Deprecated Features and Anti-Patterns in Vite

### 10.1. Legacy "require()" statements

* **Avoid:** Using Node.js style "require()" statements in favor of modern ESM "import" statements.

* **Why:** "import" statements are more efficient for tree shaking and produce smaller bundles. Also, mixing module systems can increase complexity.

"""javascript

// Anti-pattern (CommonJS)

const fs = require('fs');

// Preferred ESM syntax

import fs from 'fs';

"""

### 10.2 Global Scope Pollution

* **Avoid:** Adding variables and functions directly to the global scope (e.g., "window" in browsers).

* **Why:** Can lead to unexpected conflicts if another script declares a variable with the same name.

"""javascript

// Anti-pattern: Global scope pollution

window.appVersion = '1.2.3'; // Avoid this

// Preferred: Export in a module or use a dedicated object

const appConfig = {

version: '1.2.3',

};

export default appConfig;

"""

### Example Vite Configuration (vite.config.js):

This is a comprehensive "vite.config.js" example incorporating many of the best practices mentioned above.

"""javascript

import { defineConfig } from 'vite';

import vue from '@vitejs/plugin-vue';

import { terser } from 'rollup-plugin-terser';

import { resolve } from 'path';

const API_TARGET = process.env.API_TARGET || 'http://localhost:8000';

// https://vitejs.dev/config/

export default defineConfig({

plugins: [vue()],

resolve: {

alias: {

'@': resolve(__dirname, 'src'), // Alias for easy imports

define: {

__APP_VERSION__: JSON.stringify(process.env.npm_package_version), // Expose version

server: {

hmr: true, // Enable hot module replacement

proxy: {

'/api': {

target: API_TARGET,

changeOrigin: true,

rewrite: (path) => path.replace(/^\/api/, ''),

build: {

minify: 'terser', // Enable minification

sourcemap: true, // Generate sourcemaps for debugging

rollupOptions: {

plugins: [terser()],

output: {

chunkFileNames: 'js/[name]-[hash].js', // Chunk file naming

entryFileNames: 'js/[name]-[hash].js', // Entry file naming

assetFileNames: '[ext]/[name]-[hash].[ext]', // Asset file naming

manualChunks(id) { // Vendor splitting

if (id.includes('node_modules')) {

return id

.toString()

.split('node_modules/')[1]

.split('/')[0]

.toString();

}

//Target latest browsers - updated for performance

target: 'esnext', // Target modern browser for smaller bundles

// Disable brotliSize reporting if you do not use Brotli

brotliSize: false,

manifest: true, // Generate manifest file

optimizeDeps: {

esbuildOptions: {

// Node.js polyfills for older browsers may be required

// Define global used in your project

define: {

global: 'globalThis'

// Enable/disable browser specific transform

target: "esnext",

}

});

"""

This document provides a comprehensive guide to coding style and conventions for Vite projects and is designed to be integrated with AI coding assistance tools. Continuously reviewing and adapting these standards as Vite evolves is crucial to maintaining a high-quality codebase.

Cline

This guide explains how to effectively use .clinerules with Cline, the AI-powered coding assistant.

Overview

The .clinerules file is a powerful configuration file that helps Cline understand your project's requirements, coding standards, and constraints. When placed in your project's root directory, it automatically guides Cline's behavior and ensures consistency across your codebase.

Key Concepts

Purpose of .clinerules

Defines project-specific guidelines and requirements
Enforces consistent coding standards
Establishes documentation practices
Sets testing and quality requirements
Configures error handling preferences

File Location

Place the .clinerules file in your project's root directory. Cline automatically detects and follows these rules for all files within the project.

Rule Structure

1. Project Overview

# Project Overview
project:
  name: 'Your Project Name'
  description: 'Brief project description'
  stack:
    - technology: 'Framework/Language'
      version: 'X.Y.Z'
    - technology: 'Database'
      version: 'X.Y.Z'

2. Code Standards

# Code Standards
standards:
  style:
    - 'Use consistent indentation (2 spaces)'
    - 'Follow language-specific naming conventions'
  documentation:
    - 'Include JSDoc comments for all functions'
    - 'Maintain up-to-date README files'
  testing:
    - 'Write unit tests for all new features'
    - 'Maintain minimum 80% code coverage'

3. Security Rules

# Security Guidelines
security:
  authentication:
    - 'Implement proper token validation'
    - 'Use environment variables for secrets'
  dataProtection:
    - 'Sanitize all user inputs'
    - 'Implement proper error handling'

Best Practices

Writing Effective Rules

Be Specific
- Use clear, actionable language
- Provide examples where helpful
- Define measurable criteria
Maintain Organization
- Group related rules together
- Use consistent formatting
- Keep critical rules at the top
Regular Updates
- Review rules periodically
- Update based on team feedback
- Document changes in version control

Common Patterns

# Common Patterns Example
patterns:
  components:
    - pattern: 'Use functional components by default'
    - pattern: 'Implement error boundaries for component trees'
  stateManagement:
    - pattern: 'Use React Query for server state'
    - pattern: 'Implement proper loading states'

Integration with Development Workflow

Using with Version Control

Commit the Rules
- Include .clinerules in version control
- Document rule changes in commit messages
- Review rule changes as part of PR process
Team Collaboration
- Discuss rule changes with team
- Maintain changelog for rule updates
- Ensure all team members understand rules

Troubleshooting

Common Issues

Rules Not Being Applied
- Verify file location (must be in root directory)
- Check file formatting
- Ensure Cline has access to the file
Conflicting Rules
- Review rule hierarchy
- Resolve conflicts explicitly
- Document rule precedence
Performance Considerations
- Keep rules concise and focused
- Avoid overly complex rule structures
- Regular cleanup of obsolete rules

Examples

Basic Project Setup

# Basic .clinerules Example
project:
  name: 'Web Application'
  type: 'Next.js Frontend'
  standards:
    - 'Use TypeScript for all new code'
    - 'Follow React best practices'
    - 'Implement proper error handling'

testing:
  unit:
    - 'Jest for unit tests'
    - 'React Testing Library for components'
  e2e:
    - 'Cypress for end-to-end testing'

documentation:
  required:
    - 'README.md in each major directory'
    - 'JSDoc comments for public APIs'
    - 'Changelog updates for all changes'

Advanced Configuration

# Advanced .clinerules Example
project:
  name: 'Enterprise Application'
  compliance:
    - 'GDPR requirements'
    - 'WCAG 2.1 AA accessibility'

architecture:
  patterns:
    - 'Clean Architecture principles'
    - 'Domain-Driven Design concepts'

security:
  requirements:
    - 'OAuth 2.0 authentication'
    - 'Rate limiting on all APIs'
    - 'Input validation with Zod'

Code Style and Conventions Standards for Vite

Cline

Overview

Key Concepts

Purpose of .clinerules

File Location

Rule Structure

1. Project Overview

2. Code Standards

3. Security Rules

Best Practices

Writing Effective Rules

Common Patterns

Integration with Development Workflow

Using with Version Control

Troubleshooting

Common Issues

Examples

Basic Project Setup

Advanced Configuration

Related Rules

Core Architecture Standards for Vite

Testing Methodologies Standards for Vite

Component Design Standards for Vite

State Management Standards for Vite

Performance Optimization Standards for Vite