sroxck

sroxck

HomeArchives

Record the experience of setting up the vite-wide project

71
AI Translation
This post is translated from Chinese into English through AI.View Original
AI-generated summary
The project involves setting up an independent admin backend management system and a web frontend display system, both built with Vite. They share common components and methods but maintain separate configurations and plugins. Each project is packaged individually, utilizing tree shaking to optimize build size by only including necessary resources. **Requirements:** - Manage both systems within a single project while allowing them to operate independently. - Support tree shaking for efficient packaging. **Why Not Use Pages or Monorepo?** - **Pages Approach:** Leads to large bundle sizes and inflexible configurations. - **Monorepo Approach:** Adds complexity for small to medium projects, requires full repository builds, and complicates dependency management. **Project Structure:** - The project includes directories for `admin`, `web`, `shared` components, `plugins`, `scripts`, `types`, and `config`. - Each system has its own Vite configuration, with a shared configuration for common settings. **Type Support:** - Provides comprehensive type support across modules, ensuring strong type checking for components and functions. **Common Issues and Solutions:** - Configuration issues are resolved by allowing independent Vite configurations. - TypeScript issues are addressed by using a unified tsconfig. - Public component type issues are managed through paths configuration in tsconfig. Overall, the project aims for modularity, efficiency, and flexibility in development and deployment.

Build a system that includes an admin backend management system and a web frontend display system, each independently built with Vite, sharing only common components and methods. The project supports setting individual Vite configurations and plugins separately from the global configuration, and each project will be packaged separately. Vite will build according to the dependencies and shared resources as needed.

Requirements Organization#

The requirement is to manage the admin backend management system and the web frontend display system within one project. They are independent, can use content from the shared package, are packaged separately, and support tree shaking.

Why Not?#

Why not use the pages solution?#

  1. Bulky Build: The pages solution typically packages all pages, components, and dependencies together, resulting in both admin and web being packaged into one bundle, leading to larger final build file sizes and affecting loading speed.

    This project ensures that each project only imports the resources and dependencies actually used through Tree Shaking, optimizing the package size.

  2. Lack of Flexibility: When using the pages solution, the project structure and configuration are often fixed, only allowing for a unified configuration, making it difficult to adjust flexibly.

    This project supports independent configuration and plugin management, allowing developers to freely adjust project structure and build configuration according to needs. Each module is a separate Vite project.

  3. Operational Complexity: The pages solution requires additional operational coordination.

    This project simply triggers deployment based on the directory of the changed files.

Why not use the Monorepo solution?#

  1. Project Complexity: The Monorepo solution is suitable for large projects, but for small or medium-sized projects, the complexity of managing multiple packages may lead to decreased development efficiency.

    This project provides independent module management, avoiding unnecessary complexity.

  2. Build Time: In a Monorepo, it may be necessary to build the entire repository each time, even if only one module has been modified. This can increase build time.

    This project supports on-demand builds, enabling quick responses to development needs.

  3. Dependency Management: The Monorepo solution requires meticulous management of dependencies between various modules, which may increase maintenance costs.

    This project simplifies dependency management through shared directories and independent configurations.

Project Setup#

The project directory is as follows
dir

The tsconfig is as follows

// [tsconfig.json]
{
  "files": [],
  "compilerOptions": {
    "module": "NodeNext"
  },
  "references": [
    { "path": "./tsconfig.app.json" },
    { "path": "./tsconfig.node.json" }
  ]
}

// [tsconfig.node.json]
{
  "extends": "@tsconfig/node20/tsconfig.json",
  "include": [
    "vite.config.*",
    "vitest.config.*",
    "cypress.config.*",
    "nightwatch.conf.*",
    "playwright.config.*"
  ],
  "compilerOptions": {
    "composite": true,
    "noEmit": true,
    "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.node.tsbuildinfo",

    "module": "ESNext",
    "moduleResolution": "Bundler",
    "types": ["node"]
  }
}

// [tsconfig.app.json]
{
  "extends": "@vue/tsconfig/tsconfig.dom.json",
  "include": [
    "env.d.ts",
    "packages/**/*",
    "packages/**/*.vue",
    "packages/**/*.tsx",
    "./config.global.ts"
  ],
  "exclude": ["packages/**/__tests__/*"],
  "compilerOptions": {
    "allowImportingTsExtensions": true,
    "composite": true,
    "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.app.tsbuildinfo",
    "baseUrl": ".",
    "paths": {
      "@shared/*": ["./packages/shared/*"]
    }
  }
}

The config is as follows

// [config.global.ts]
import path from "path";
import { plugins } from "./plugins";
export const sharedConfig = {
  commonPlugins: [...plugins],
  resolve: {
    alias: {
      "@shared": path.resolve(__dirname, "./packages/shared"),
    },
  },
};

// [plugins/index.ts]
import AutoImport from "unplugin-auto-import/vite";
import Components from "unplugin-vue-components/vite";
import vue from "@vitejs/plugin-vue";
import { ElementPlusResolver } from "unplugin-vue-components/resolvers";
import { PluginOption } from "vite";
import vueJsx from "@vitejs/plugin-vue-jsx";
export const plugins: PluginOption[] = [
  vue(),
  vueJsx(),
  AutoImport({
    resolvers: [ElementPlusResolver()],
  }),
  Components({
    resolvers: [ElementPlusResolver()],
  }),
];

// [web/vite.config.ts]
import { defineConfig } from "vite";
import path from "path";
import { sharedConfig } from "../../config.global.ts";
const { commonPlugins, ...commonConfig } = sharedConfig;
export default defineConfig({
  plugins: [...commonPlugins],
  root: path.resolve(__dirname),
  ...commonConfig,
});

// [admin/vite.config.ts]
import { defineConfig } from "vite";
import path from "path";
import { sharedConfig } from "../../config.global.ts";
const { commonPlugins, ...commonConfig } = sharedConfig;
export default defineConfig({
  plugins: [...commonPlugins],
  root: path.resolve(__dirname),
  ...commonConfig,
});

Type Support#

Unified configuration, multi-module usage, the project provides complete and clearly structured type support, including support for tsx, vine, and macros. SFC components, pure function components, and tsx components in any module will receive complete type support, including automatic props and emits type strong validation and ref instance type support.

Summary of Issues#

  1. Configuration Issues
    The solution is for each to have their own vite configuration, and then the root directory configures a unified vite configuration, allowing each to set their own independent configuration.

  2. TypeScript Issues
    The solution is to use a unified tsconfig, delete each one's tsconfig, and use the tsconfig from create-vue (directly taken over, dependencies installed according to create-vue's package).

  3. TSX Support
    Using tsx is supported by default in create-vue. It should be noted that the include in tsconfig should wrap both admin and web. However, the best solution is to create a packages directory to place admin, web, and shared, and the include field should only contain this directory, but the unified vite configuration file should be wrapped.

  4. Common Component Type Issues
    Configure the paths field in tsconfig, and set the paths in compilerOptions as follows

 "paths": {
      "@shared/*": ["./packages/shared/*"]
  }

Directory Structure#

Packages Directory#

The packages directory is the project module directory, containing the following content:

  • admin: Backend management system, built with Vite.

  • web: Frontend display system, built with Vite.

  • shared: Common directory for shared components and methods, used by both admin and web systems.

Plugins Directory#

The plugins directory is for centralized management of Vite plugins. Custom plugins and third-party plugins are exported through a unified entry file index.ts, facilitating unified management and usage.

Custom Plugin Specifications

  1. Plugin Naming: Use lowercase letters, with words separated by hyphens (e.g., my-custom-plugin).
  2. Plugin Structure: Each plugin should include an install method for registering the plugin in Vite.
  3. Documentation: Each plugin should include usage examples and configuration instructions for other developers to understand and use.

Scripts Directory#

The scripts directory contains project build scripts and other task scripts, mainly for automating builds, testing, and deployment tasks. Specific scripts can be added as needed.

Types Directory#

The types directory is for storing TypeScript type declaration files .d.ts. Global type module declarations can be added in this directory for use throughout the project.

Config Directory#

The config directory stores the project's global configuration files, including Vite configurations, environment variables, and other related settings. Configurations can be adjusted according to different environments (development, testing, production).

This article was synchronized and updated to xLog by Mix Space Original link: http://www.sroxck.top/posts/note/wide

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.