Skip to main content
Module

std/.github/CONTRIBUTING.md

The Deno Standard Library
denoland/deno_std
Go to Latest
File

Contributing Guide

Code of Conduct, Style Guide and Architecture Guide

Please read our code of conduct, style guide and architecture guide before contributing.

Issues

  1. Check for existing issues before creating a new one.
  2. When creating an issue, be clear, provide as much detail as possible and provide examples, when possible.

Pull Requests

  1. Install the Deno CLI.
  2. Fork and clone the repository.
  3. Set up git submodules:
    git submodule update --init
  4. Create a new branch for your changes.
  5. Make your changes and ensure deno task ok passes successfully.
  6. Commit your changes with clear messages.
  7. Submit a pull request with the sub-module in question, and a clear title and description, as follows:
    • fix(http): fix race condition in server
    • docs(fmt): update docstrings
    • feat(log): handle nested messages

Deprecations

  1. See the deprecation policy for how deprecations work.

  2. Start creating a pull request by adding a deprecation notice to the given symbol with the following format, including the removal version and links to any relevant replacement symbols or documentation:

    // /sub/foo.ts
/**
 * @deprecated (will be removed in 0.215.0) Use {@linkcode bar} instead.
 */
export function foo() {}

  3. Submit a pull request starting with the following format:

    deprecation(sub): `foo()`

Tests

Test names

Use a test name that includes the symbol in question and the test criteria, in plain language, as follows:

  • assertEquals() matches when values are equal
  • ensureDirSync() creates dir if it does not exist
  • Server exposes the addresses the server is listening on as addrs property

Documentation

Documentation must be clear, concise and thorough, and be written in JSDoc syntax. In general, the documentation style should be as close to the MDN Web Docs as possible.

Public symbols

For public symbols, include the following pieces of documentation in the following order (if applicable):

  1. A description of the symbol, including its purpose, what it performs, and behaviors of various use cases.
  2. If it is a function, method or class, a description of each parameter using the @param tag.
  3. If it is a function or method, a description of the return value using the @returns tag.
  4. At least one minimal example code snippet using the @example tag for basic usage. The reader should be able to copy and execute the code snippet with the expected values.

See the following examples: