We welcome and appreciate all contributions to Deno.
This page serves as a helper to get you started on contributing.
There are numerous repositories in the
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 (codebases primarily comprise the languages in bold):
This is the main repository that provides the
If you want to fix a bug or add a new feature to
deno this is the repository
you want to contribute to.
While iterating on such modules it is recommended to include
--features __runtime_js_sources in your
cargo flags. This is a special
development mode where the JS/TS sources are not included in the binary but read
at runtime, meaning the binary will not have to be rebuilt if they are changed.
# cargo build
cargo build --features __runtime_js_sources
# cargo run -- run hello.ts
cargo run --features __runtime_js_sources -- run hello.ts
# cargo test integration::node_unit_tests::os_test
cargo test --features __runtime_js_sources integration::node_unit_tests::os_test
Also remember to reference this feature flag in your editor settings. For VSCode users, combine the following into your workspace file:
The standard library for Deno.
Languages: TypeScript, WebAssembly
The next-gen web framework.
Languages: TypeScript, TSX
Linter that powers
deno lint subcommand.
Documentation generator that powers
deno doc subcommand and
Frontend for documentation generator: https://doc.deno.land
Languages: TypeScript, TSX, CSS
Library that provides bijection layer between V8 and Rust objects. Based on
serde library. Very technical and low-level.
Official Docker images for Deno.
Read the style guide.
Please don't make the benchmarks worse.
Ask for help in the community chat room.
If you are going to work on an issue, mention so in the issue's 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 will be accepted. We don't want you to spend hours working on code that might not be accepted.
Submitting a pull request
Before submitting a PR to any of the repos, please make sure the following is done:
- Give the PR a descriptive title.
Examples of good PR title:
- fix(std/http): Fix race condition in server
- docs(console): Update docstrings
- feat(doc): Handle nested re-exports
Examples of bad PR title:
- fix #7123
- update docs
- fix bugs
- Ensure there is a related issue and that it is referenced in the PR text.
- Ensure there are tests that cover the changes.
In addition to the above make sure that:
cargo testpasses - this will run full test suite for
denoincluding unit tests, integration tests and Web Platform Tests
./tools/format.js- this will format all of the code to adhere to the consistent style in the repository
clippy(for Rust) and
In addition to the above make sure that:
All of the code you wrote is in
TypeScript(ie. don't use
deno test --unstable --allow-allpasses - this will run full test suite for the standard library
deno fmtin the root of repository - this will format all of the code to adhere to the consistent style in the repository.
deno lint- this will check TypeScript code for common mistakes and errors.
First, please be sure to
Then, please ensure
deno task ok is run and successfully passes.
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.
All publicly exposed APIs and types, both via the
deno module as well as the
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:
/** A simple JSDoc comment */
export const FOO = "foo";
Find more at: https://jsdoc.app/
Use this guide for writing documentation comments in Rust code.