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

Symbols and modules are documented using the JSDoc syntax. It should be written in the same style as the MDN Web Docs.

Public symbols

Documentation for public symbols should contain:

1. A description, first
2. @param tags for each parameter and a @returns tag, if the symbol is a function.
3. At least one example code snippet using the @example tag and a title. The code is reproducible when copied and pasted as a script.

See the source code within std/datetime for examples.

Module documentation

Module files, or mod.ts files, should have the following:

1. A high-level description of the package.
2. Sections providing brief overviews of the APIs within the package, including minimal example code snippets (without the @example tag).
3. A @module to denote module documentation.

See the source code for std/datetime/mod.ts as an example.