Hi! Thanks for your interest in contributing to the project. Before contributing, make sure you read the contribution guide: it will help you get started with the repo, the tools used and the project workflow.
Important
I try to maintain this project as much as I can, but sometimes issues and PRs may take some time before being considered. Thank you for being patient!
This repo uses pnpm as package manager.
It is also recommended you have Corepack enabled.
To set the repository up:
| Step | Command |
|---|---|
| 1. Install Node.js, using the current or latest LTS | - |
| 2. Enable Corepack | corepack enable |
| 3. Install pnpm | npm i -g pnpm |
| 4. Install dependencies under the project root | pnpm install |
All of the plugin (and Nuxt module) source code lives under the src/ folder. The plugin is built "Nuxt first" with a Vue-only plugin built aside.
The core logic of persistence and hydration is located in src/runtime/core.ts and types are located in src/runtime/
The Nuxt module is defined in src/module.ts with (auto-imported) runtime code located in src/runtime/.
The standalone Pinia plugin for Vue-only apps is exported from src/index.ts.
A playground in the form of a Nuxt app is located in playground and serves as the development platform for the plugin/module.
Documentation lives under the docs/ folder and is powered by vitepress.
Runs the Nuxt playground as a dev server with the Nuxt module loaded.
Builds the package for production into dist/ using:
@nuxt/module-builderfor the Nuxt module.tsupfor the standalone plugin.rollupfor the UMD build of the standalone plugin.
Subcommands are available to build parts separately.
Runs ESLint. Also servers as formatter through Stylistic.
To resolve auto-fixable issues, run pnpm run lint:fix.
Runs the vitepress dev server for the documentation website.
Use pnpm run docs:build to generate a production build of the documentation.
Before you start to work on a feature pull request, it's always better to open a feature request issue first to discuss whether the feature is desired/needed and how it could/should be implemented. This would help save time for both the maintainers and the contributors and help features to be shipped faster.
This repo uses Conventional Commits.
git commit -m '<type>: <description>'type: the kind of change to commit (fix, feat, docs...).description: a brief description of the change.
When submitting a pull request, make sure your PR's title also follows the commit convention.
If your PR fixes or resolves an existing issue, please link it in your PR description (replace 123 with a real issue number):
fixes #123Commits in the PR don't matter as they are squashed and merged into a single commit.
Thanks for reading the guide and happy contributing!