Contributing

Thanks for being interested in contributing to this project!

Warning: ⚠️ Slowing down new functions

As the VueUse audience continues to grow, we have been inundated with an overwhelming number of feature requests and pull requests. As a result, maintaining the project has become increasingly challenging and has stretched our capacity to its limits. As such, in the near future, we may need to slow down our acceptance of new features and prioritize the stability and quality of existing functions. Please note that new features for VueUse may not be accepted at this time. If you have any new ideas, we suggest that you first incorporate them into your own codebase, iterate on them to suit your needs, and assess their generalizability. If you strongly believe that your ideas are beneficial to the community, you may submit a pull request along with your use cases, and we would be happy to review and discuss them. Thank you for your understanding.

Development

Setup

Clone this repo to your local machine and install the dependencies.

pnpm install

We use VitePress for rapid development and documenting. You can start it locally by

pnpm dev

Testing

pnpm test:unit # to run unit tests

If you want to use experimental browser tests, you need to install playwright dependencies first.

npx playwright install --with-deps

and then run

pnpm test:browser

Contributing

Existing functions

Feel free to enhance the existing functions. Please try not to introduce breaking changes.

New functions

There are some notes for adding new functions

• Before you start working, it's better to open an issue to discuss first.
• The implementation should be placed under packages/core as a folder and exposing in index.ts
• In the core package, try not to introduce 3rd-party dependencies as this package is aimed to be as lightweight as possible.
• If you'd like to introduce 3rd-party dependencies, please contribute to @vueuse/integrations or create a new add-on.
• You can find the function template under packages/core/_template/, details explained in the Function Folder section.
• When writing documentation for your function, the <!--FOOTER_STARTS--> and <!--FOOTER_ENDS--> will be automatically updated at build time, so don't feel the need to update them.

Please note you don't need to update packages' index.ts. They are auto-generated.

New add-ons

New add-ons are greatly welcome!

• Create a new folder under packages/, name it as your add-on name.
• Add add-on details in scripts/packages.ts
• Create README.md under that folder.
• Add functions as you would do to the core package.
• Commit and submit as a PR.

Project Structure

Monorepo

We use monorepo for multiple packages

packages
  shared/         - shared utils across packages
  core/           - the core package
  firebase/       - the Firebase add-on
  [...addons]/    - add-ons named

Function Folder

A function folder typically contains these 4 files:

You can find the template under packages/core/_template/

index.ts            # function source code itself
demo.vue            # documentation demo
index.test.ts       # vitest unit testing
index.md            # documentation

for index.ts you should export the function with names.

// DO
export { useMyFunction }

// DON'T
export default useMyFunction

for index.md the first sentence will be displayed as the short intro in the function list, so try to keep it brief and clear.

# useMyFunction

This will be the intro. The detail descriptions...

Read more about the guidelines.

Code Style

Don't worry about the code style as long as you install the dev dependencies. Git hooks will format and fix them for you on committing.

@__NO_SIDE_EFFECTS__ with function overloads

For overloaded functions, add @__NO_SIDE_EFFECTS__ in two places:

1. In the public JSDoc, for API documentation.
2. Immediately before the implementation, for build tools.

/**
 * ...
 *
 * @__NO_SIDE_EFFECTS__
 */
export function useFoo(value: string): string
export function useFoo(value: number): number
/* @__NO_SIDE_EFFECTS__ */
export function useFoo(value: string | number): string | number {
  // ...
}

TypeScript removes overload signatures during compilation, so the JSDoc annotation does not reach the bundler. Keep the one-line annotation before the implementation; there is no need to duplicate the full JSDoc.

@__NO_SIDE_EFFECTS__ with arrow functions

For arrow functions, place the compact build annotation immediately before the function expression for the bundler to recognize it.

export const useFoo: () => void = /* @__NO_SIDE_EFFECTS__ */ () => {
  // ...
}

DO NOT include the magic @__NO_SIDE_EFFECTS__ tag in the leading JSDoc of a const declaration. Unlike overload signatures, the declaration and its JSDoc are emitted to JavaScript. The tag would then appear before the variable declaration instead of the function expression and may trigger an invalid-annotation warning from the bundler.

If you want to present the information to human readers, consider using @NO_SIDE_EFFECTS (without the __) in ordinary prose instead. It will be ignored by the bundler so it won't trigger any warnings.

/**
 * ...
 *
- * @__NO_SIDE_EFFECTS__
+ * @NO_SIDE_EFFECTS
 */
export const useFoo: () => void = /* @__NO_SIDE_EFFECTS__ */ () => {
  // ...
}

Thanks

Thank you again for being interested in this project! You are awesome!