Use Liangmi VP Config
Configure projects with
, an opinionated preset for Vite+, the united JavaScript toolchain. Treat Vite+ as distinct from Vite.
Inspect the project
Before editing:
- Read the repository's and existing .
- Inspect , source entry points, workspace layout, and browser or Node.js signals.
- Check local Vite+ documentation in
node_modules/vite-plus/docs
- Preserve project-specific overrides instead of replacing them blindly.
Select a preset
Choose one category for each
:
| Category | Use for | Included parts |
|---|
| Workspace roots and projects without a clearer role | , , , |
| Node.js CLI, TUI, React Ink, or Vue TUI projects | , , , , |
| Published or reusable libraries | , , , , |
| Browser applications and websites | , , , |
In a monorepo, use
at the workspace root and choose
,
, or
for member projects. Do not mix library and website signals in one project.
Treat
as experimental. It supports browser and component linting, but Vue template linting depends on improved upstream Oxlint support.
Install with Vite+
Use Vite+ for package management:
bash
vp install -D @liangmi/vp-config
Do not use
or
directly when the project is managed by Vite+.
This preset requires
. Align the installed version with the preset's peer dependency; keep any
alias to
@voidzero-dev/vite-plus-core
on the same version.
Configure
Wrap the configuration with the selected named export:
typescript
import { lib } from '@liangmi/vp-config'
export default lib({
pack: {
entry: './src/index.ts'
}
})
The wrapper accepts the same object, function, or promise shapes as Vite+'s
. User values deeply override the preset while untouched nested defaults remain enabled.
For
and
, define
explicitly from the project's real source entry points. The preset cannot infer the package's intended public entries.
Only select parts provided by the chosen category. Do not import a preset outside
.
Since we already use vp config preset, most of the config items can be omiited. For example, we do not need to define
,
, and
config most of the time,
generation,
,
generation or
in
are also set by default. If you are doing migration works, please handle them as well.
Work with preset defaults
Assume these defaults unless the project explicitly overrides them:
- Linting uses strict, type-aware Oxlint with type checking and warnings denied. Do not add a separate check solely for type checking.
- Style rules are explicitly allowlisted to keep lint behavior stable across Oxlint upgrades. New upstream style rules stay disabled until they are reviewed and added.
- is rejected except in the category and Node.js script overrides.
- Formatting uses Oxfmt with single quotes, no semicolons, no unnecessary trailing commas, sorted imports, and sorted fields.
- packaging generates declarations with and package exports with fixed extensions.
- packaging targets Node.js, minifies, strips prefixes, and disables declaration generation.
- Staged files run .
Put task cache options (
,
,
, and
) inside
.
Use the generated cached tasks when suitable:
Run them with
or
. Package scripts may call them, for example
. If there is existing scripts calling
inside package.json, you are supposed to change them to
(Only for commands listed above.).
Migration
has a stricter ruleset, to make the linting pass after migration, you need to change runtime code to fix linting errors.
If you meet cases that can't fix easily, we prefer
than disabling one rules global in
.
Validate changes
After editing:
- Run when commit-hook configuration needs to be installed or refreshed.
- Run .
- Run the relevant build, package, or test task for the changed project.
- Fix preset-plugin errors rather than disabling them. They detect orphan configs, imports outside , missing preset wrappers, improper root or project categories, and mixed library and website signals.