# vue-types: configurable prop type definitions for Vue 3

> vue-types is a collection of configurable prop type definitions for Vue.js components, inspired by React's prop-types, published as a pnpm monorepo with separate core, Nuxt and docs packages. Its value is runtime validation with per prop configuration, and its cost is a dependency in your component API for something TypeScript users can often express at compile time instead.

**dwightjack/vue-types** — Vue3 Prop Types definitions

- Repository: https://github.com/dwightjack/vue-types
- Website: https://vue-types.codeful.dev/
- Stars: 583 · Forks: 34
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/dwightjack-vue-types

## What vue-types is for

vue-types is a collection of configurable prop type definitions for Vue.js components, inspired by React's prop-types. The inspiration is explicit and it explains the shape of the library: the familiar prop-types vocabulary, a constructor for each type, and a validator that runs at runtime and reports what is wrong with a prop value.

The word configurable is the part that matters. A plain runtime type check tells you that a prop received a string where you expected a number. A configurable one lets you attach rules to the type, so the same number type can require a range, reject NaN, or demand an integer. That is the difference between a type checker that catches mistakes and one that encodes the contract of a component library.

There is a StackBlitz link in the documentation for trying it in the browser, and the official documentation site is at vue-types.codeful.dev.

The users are Vue developers who want runtime validation on props, teams shipping a component library where consumers might pass the wrong thing, and developers coming from React who want the same mental model in Vue. The repository topics list nuxt, nuxtjs, props, proptypes, vue3 and vuejs3, which is a fair summary of the scope.

One thing to note before going further. The documentation carries a note saying the document is for VueTypes 6, and that readers looking for older versions should refer to the documentation for v2 to v5 at a separate site. The newest published package is vue-types@7.0.0 from 2026-06-08, so the version documentation and the published package have moved apart, and that is worth checking against whatever you install.

## The monorepo layout and the packages inside it

The repository is a pnpm workspace, and the root package.json is named vue-types-monorepo with the description VueTypes Monorepo, marked private so it is never published itself.

The workspace scripts show the shape of the project, because each one delegates to a filtered package:

```json
  "scripts": {
    "examples:dev": "pnpm --filter=vue-types run build && pnpm --filter=examples start",
    "docs:dev": "pnpm --filter=docs run dev",
    "nuxt:dev": "pnpm --filter=vue-types-nuxt stub && pnpm --filter=vue-types-nuxt-playground dev",
    "build": "pnpm -r build",
    "lint": "pnpm -r lint",
    "test": "pnpm -r test",
  },
```

So there are at least three filtered packages in the workspace, vue-types itself, a vue-types-nuxt package and a docs package, and there is also a nuxt playground, plus an examples package that the examples:dev script starts after building the core.

The Nuxt binding has its own published version line. vue-types-nuxt@5.0.0 was published on 2026-06-08, the same day as vue-types@7.0.0, and vue-types-nuxt@4.0.0 came on 2025-08-19. The two packages are released together, which is convenient when you consume both and awkward when you only want one.

The Nuxt package exists because Vue's prop definition is not the only place a component's contract is expressed. Nuxt projects and other meta-frameworks read the props from a different place, and the separate package adapts the vue-types definitions for that environment rather than making the core package aware of it.

## The toolchain: pnpm, Node 20, oxlint and Vitest

The root manifest pins the toolchain precisely, and for a library that others depend on, those pins are the interesting part.

```json
  "packageManager": "pnpm@11.5.0",
  "engines": {
    "node": ">=20.0.0",
    "pnpm": "^11.5.0"
  },
```

So the project requires Node 20 or newer and pnpm 11, and the packageManager field means a contributor with corepack enabled gets that exact pnpm version rather than whatever is installed.

The linting and formatting stack is not the usual ESLint and Prettier pairing. The devDependencies list oxfmt at 0.52.0, oxlint at 1.67.0 and oxlint-tsgolint at 0.23.0, with a matching .oxfmtrc.json and .oxlintrc.json in the tree, and a lefthook.yml for Git hooks with lefthook itself at 2.1.8. That is a move to the Oxc family of tools, which are written in Rust, and it tells you the project is keeping its lint and format step fast.

Testing is Vitest, at 4.1.11, with the v8 coverage provider at 4.1.7 and happy-dom at 20.9.0 as the DOM environment, with a vitest.setup.ts file at the root. The build tooling is Vite at 8.0.16 with TypeScript at 6.0.3, and there is a vite.config.ts.

Two publishing safeguards are in the dev dependency list and worth noticing. publint at ^0.3.21 checks that a published package's exports and entry points resolve correctly, which catches a whole class of packaging mistakes. And the release process uses changesets, with the ci:version and ci:publish scripts driving pnpm changeset version and pnpm -r publish, and a .changeset/ directory in the tree.

## Running the examples and the docs on your machine

The documentation gives the same three step recipe twice, once for the examples and once for the docs site, and the difference is only the script name.

For the examples, the steps are to install dependencies with pnpm install, run the script pnpm run examples:dev, and wait for the server and bundler to start up. For the docs, the steps are pnpm install followed by pnpm run docs:dev.

The contributing section then fills in the rest of the loop: clone the repository, install dependencies, make your changes, update or add tests in packages/core/__tests__/, verify that everything works with pnpm -r run lint && pnpm -r test, and submit a pull request.

That path is worth noting because it tells you where the tests live. The tests are under packages/core/__tests__/, which confirms that packages/core is the directory that holds the core package, and it is the one to watch when you change the type definitions.

The verification command is the same lint and test recursion the root package.json defines, run across every workspace package rather than only the core. So a change in the Nuxt package is linted and tested the same way, and pnpm -r run lint && pnpm -r test is the single command to run before opening a pull request.

The examples script is also worth noting for a different reason. examples:dev first builds the vue-types package and then starts the examples app, so the examples always run against a freshly built library rather than a stale one.

## Where vue-types is the wrong choice

The first limit is the obvious one for a TypeScript-first team. If your components already declare props with defineProps and a type-only declaration, the compiler checks the shape at build time and catches a wrong type before the code ships. A runtime validator on top of that is not free: it runs on every prop assignment in development, it duplicates a contract you have already expressed, and the two can disagree, because a runtime validator cannot see a type the compiler accepted.

The second is that runtime validation is a development and test concern, not a production guarantee. The value of a prop-type library is the error message you get during development. It does not protect a deployed application from a bad prop at runtime.

The third is the version drift in the documentation. The README document is described as covering VueTypes 6, older versions are pointed at a separate site for v2 to v5, and the published package is at 7.0.0. Anyone following the documentation and installing the current package is reading a document for a different major version, and the prop-types API changed between those majors.

The fourth is the toolchain weight. The library itself is small, but developing it requires Node 20, pnpm 11, a pnpm workspace, Oxc tooling, Vitest and changesets, and the workspace layout means a bug fix in the core package has to be released and picked up in the Nuxt package and the docs separately.

Compare that with writing your own prop validators. The difference in approach is that vue-types gives you a curated set of types with configuration rules already designed, in a shape Vue components can consume directly, while a hand written validator is a few lines of a function in your own codebase that you maintain alone. If you only need to check a handful of props on a couple of components, the hand written version is less machinery. If you are building a component library where the contract needs to be precise and shared, the library earns its place.

## Licence, release cadence and the state of the tree

vue-types is released under the MIT licence, with the text in the LICENSE file at the repository root, and the README credits the MIT licence and the copyright of Marco Solazzi from 2016 to present. The root package.json also carries an MIT licence field for the monorepo itself.

The MIT terms matter for a prop type library because it is the kind of dependency that ends up in the dependency tree of a commercial application, and a permissive licence with no copyleft obligation is the least friction.

On cadence, the release history shows two packages moving together. vue-types@7.0.0 and vue-types-nuxt@5.0.0 were both published on 2026-06-08, with vue-types-nuxt@4.0.0 in August 2025. The repository is not archived, and the last push was on 2026-10-22, so the tree is a day old relative to today.

The tree itself is the modern JavaScript package layout. There is a packages/ directory holding the workspace members, a pnpm-workspace.yaml, a pnpm-lock.yaml, a.changeset/ directory for the release notes, a.nvmrc pinning the Node version, a.vscode/ directory, a tsconfig.json, a vite.config.ts, a vitest.setup.ts, an.editorconfig, and a public-key.asc file. Renovate is present with a renovate.json, so dependency updates are automated rather than manual, and lefthook.yml runs the Git hooks.

What to verify first is narrow. Install the version you intend to use and read the documentation for that version rather than the one linked in the README, then decide whether the runtime validation earns its place next to your existing type declarations, and if you use the Nuxt package, check that the version of vue-types-nuxt you take is compatible with the vue-types version it depends on, since the two are released on their own schedule.

## Conclusion

vue-types fits a Vue team that wants runtime prop validation with configurable rules, wants to share a prop contract between a component library and its consumers, or is porting code from React and wants the same prop-types vocabulary. It does not fit a TypeScript-first codebase whose props are already fully typed, because the runtime validator then duplicates what the compiler already guarantees. Before adopting it, check whether your components already declare their props with defineProps and type-only syntax, read the v2 to v5 documentation if you are migrating from an older release, and confirm the version you install matches the documentation, since the README still refers to VueTypes 6 while the newest published package is 7.0.0.

## FAQ

### What is vue-types and what is it based on?

vue-types is a collection of configurable prop type definitions for Vue.js components, inspired by React's prop-types. The configuration is the point: rules such as ranges or extra validation can be attached to a type, not just a primitive check.

### How do I run the vue-types examples locally?

Install dependencies with pnpm install, then run pnpm run examples:dev and wait for the server and bundler to start up. The script builds the vue-types package first and then starts the examples app, so the examples run against a fresh build.

### How do I run the vue-types documentation site locally?

Run pnpm install and then pnpm run docs:dev. The contributing section adds that changes need tests under packages/core/__tests__/ and a verification step of pnpm -r run lint && pnpm -r test before opening a pull request.

### Is there a Nuxt version of vue-types?

Yes, a separate vue-types-nuxt package. vue-types-nuxt@5.0.0 was published on 2026-06-08 alongside vue-types@7.0.0, and the root scripts include a nuxt:dev task that stubs the package and starts a nuxt playground.

### What licence does vue-types use and how often is it released?

vue-types is released under the MIT licence, with the terms in the LICENSE file at the repository root and the copyright of Marco Solazzi from 2016 to present. The repository is not archived and the last push was on 2026-10-22.

## Sources

- [dwightjack/vue-types on GitHub](https://github.com/dwightjack/vue-types)
- [License: MIT](https://github.com/dwightjack/vue-types/blob/main/LICENSE)
- [Project website](https://vue-types.codeful.dev/)
- [README](https://github.com/dwightjack/vue-types/blob/main/README.md)
- [Releases](https://github.com/dwightjack/vue-types/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dwightjack-vue-types