Contributing

    • Ask for help in the .

    • If you are going to work on an issue, mention so in the issue comments before you start working on the issue.

    • If you are going to work on a new feature, create an issue and discuss with other contributors before you start working on the feature.

    • Please be professional in the forums. We follow Rust’s code of conduct (CoC). Have a problem? Email .

    Before submitting, please make sure the following is done:

    1. Give the PR a descriptive title.

    Examples of good PR title:

    • fix(std/http): Fix race condition in server
    • docs(console): Update docstrings

    Examples of bad PR title:

    • fix #7123
    • update docs
    • fix bugs
    1. Ensure there is a related issue and it is referenced in the PR text.
    2. Ensure there are tests that cover the changes.
    3. Ensure passes.
    4. Ensure ./tools/format.js passes without changing files.

    We are very concerned about making mistakes when adding new APIs. When adding an Op to Deno, the counterpart interfaces on other platforms should be researched. Please list how this functionality is done in Go, Node, Rust, and Python.

    As an example, see how Deno.rename() was proposed and added in PR #671.

    It is important to document public APIs and we want to do that inline with the code. This helps ensure that code and documentation are tightly coupled together.

    All publicly exposed APIs and types, both via the module as well as the global/window namespace should have JSDoc documentation. This documentation is parsed and available to the TypeScript compiler, and therefore easy to provide further downstream. JSDoc blocks come just prior to the statement they apply to and are denoted by a leading before terminating with a */. For example:

    `

    `

    Find more at: