Contributing

    This page serves as a helper to get you started on contributing.

    There are numerous repositories in the denoland organization that are part of the Deno ecosystem.

    Repositories have different scopes, use different programming languages and have varying difficulty level when it comes to contributions.

    To help you decide which repository might be the best to start contributing (and/or falls into your interest), here’s a short comparison (languages in bold comprise most of the codebase):

    This is the main repository that provides the deno CLI.

    If you want to fix a bug or add a new feature to this is the repository you want to contribute to.

    Languages: Rust, JavaScript

    deno_std

    The standard library for Deno.

    Languages: TypeScript, WebAssembly.

    dotland

    Frontend for official Deno webpage:

    Languages: TypeScript, TSX, CSS

    Linter that powers deno lint subcommand.

    Languages: Rust

    Documentation generator that powers deno doc subcommand and https://doc.deno.land

    docland

    Frontend for documentation generator:

    Languages: TypeScript, TSX, CSS

    Rust bindings for the V8 JavaScript engine. Very technical and low-level.

    Languages: Rust

    Library that provides bijection layer between V8 and Rust objects. Based on serde library. Very technical and low-level.

    Languages: Rust

    Official Docker images for Deno.

    • Read the .

    • Please don’t make the benchmarks worse.

    • 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; we appreciate all contributions, but not all proposed features are getting accepted. We don’t want you to spend hours working on a code that might not be accepted.

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

    Before submitting a PR to any of the repos, please make sure the following is done:

    1. Give the PR a descriptive title.
    • fix(std/http): Fix race condition in server
    • feat(doc): Handle nested re-exports

    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.

    Submitting a PR to

    Additionally to the above make sure that:

    1. cargo test passes - this will run full test suite for including unit tests, integration tests and Web Platform Tests

    2. Run ./tools/format.js - this will format all of the code to adhere to the consistent style in the repository

    3. Run ./tools/lint.js - this will check Rust and JavaScript code for common mistakes and errors using clippy (for Rust) and dlint (for JavaScript)

    Additionally to the above make sure that:

    1. All of the code you wrote is in TypeScript (ie. don’t use JavaScript)

    2. deno test --unstable --allow-all passes - this will run full test suite for the standard library

    3. Run deno fmt in the root of repository - this will format all of the code to adhere to the consistent style in the repository.

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

    JavaScript and TypeScript

    All publicly exposed APIs and types, both via the deno 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:

    Rust

    Use for writing documentation comments in Rust code.