Repo Structure

In this section, we will explore the current Deno repository structure, such that you won't feel lost.
Here is the link to the repo:
We will list some of the important directories/files you might need to interact with, and briefly introduce each of them:
build_extra/: Some customized rules of building Deno
js/: TypeScript Frontend
libdeno/: C/C++ Middle-end
src/: Rust Backend
tests/: Integration Tests
third_party/: Third party code
tools/: Deno tools for testing and building
# FILES Main Deno build rules
Cargo.toml: Dependency info for Rust end
package.json: Node dependencies (mostly for TypeScript compiler and Rollup) Cargo build rules


Some customized rules for building Deno, consisting of rules for FlatBuffers and Rust crates at the moment.
One important file you might want to pay attention to is build_extra/rust/ When adding a new Rust crate in third_party/, we need to add an entry into this file. For example, this is the rule for building a crate called time:
rust_crate("time") {
# Where is this crate?
source_root = "$registry_github/time-0.1.40/src/"
# What are its dependencies?
extern = [
(rust_crate GN template is defined in build_extra/rust/rust.gni)


This is where code for TypeScript frontend is located. Most APIs are defined in its own file, accompanied with a test file. For example, readFile is defined in read_file.ts, while its unit tests are in read_file_test.ts.
Besides files for API, here are some other special files:
  1. 1.
    main.ts: denoMain is defined in this file, which is invoked by Rust backend as the entry for bootstrapping TypeScript code.
  2. 2.
    globals.ts: All globals that do not need imports are attached here.
  3. 3.
    deno.ts: All deno namespace APIs are exported here.
  4. 4.
    libdeno.ts: Type definition for customized V8 API exposed to TypeScript.
  5. 5.
    unit_tests.ts: All unit tests are imported here and executed.
  6. 6.
    compiler.ts: Customized TypeScript compilation logic for Deno.


The C/C++ libdeno middle-end lives here.
  1. 1. libdeno APIs that are exposed and callable from the Rust side
  2. 2. code that handles interaction with V8 and where V8 C++ bindings are added. These APIs are exposed Rust and TypeScript side both.
  3. 3. logic for creating V8 snapshot during build.


The Rust backend lives here.
  1. 1. exposes libdeno APIs from libdeno/ to Rust
  2. 2. extracts V8 isolate (an isolated instance of V8 engine) and event loop creation logic using libdeno APIs
  3. 3. contains logic for Deno module file resolution and caching
  4. 4. where each Deno Op (operation) is handled. This is where the actual file system and network accesses are done.
  5. 5. contains main function for Rust. This is the ACTUAL entry point when you run the Deno binary.
  6. 6.
    msg.fbs: FlatBuffers definition file for message structure, used for message passing. Modify this file when you want to add or modify a message structure.


Integration tests for Deno.
*.jsor *.ts files define the code to run for each test. *.test defined how should this test be executed. Usually, *.out defines the expected output of a test (the actual name is specified in *.test files)
See tests/ for more details.


Third party code for Deno. Contains actual node modules, v8, Rust crate code and so on. It is placed in


Mostly Python scripts for a range of purposes.
  1. 1. Builds Deno
  2. 2. Setup and necessary code fetching
  3. 3. Code formatting
  4. 4. Code linting
  5. 5. Sync third_party code after user modifies package.json, Cargo.toml , etc.

Contains the most important Deno build logic. We will visit this file later in the example of adding a new Deno call.

Defines cargo build logic. Internally invokes