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: https://github.com/denoland/deno
We will list some of the important directories/files you might need to interact with, and briefly introduce each of them:
# DIRECTORIES
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
BUILD.gn: Main Deno build rules
Cargo.toml: Dependency info for Rust end
package.json: Node dependencies (mostly for TypeScript compiler and Rollup)
build.rs: 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/BUILD.gn
. 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
:
{% code-tabs %} {% code-tabs-item title="build_extra/rust/BUILD.gn" %}
rust_crate("time") {
# Where is this crate?
source_root = "$registry_github/time-0.1.40/src/lib.rs"
# What are its dependencies?
extern = [
":libc",
":winapi",
]
}
{% endcode-tabs-item %} {% endcode-tabs %}
(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:
main.ts
:denoMain
is defined in this file, which is invoked by Rust backend as the entry for bootstrapping TypeScript code.globals.ts
: All globals that do not need imports are attached here.deno.ts
: Alldeno
namespace APIs are exported here.libdeno.ts
: Type definition for customized V8 API exposed to TypeScript.unit_tests.ts
: All unit tests are imported here and executed.compiler.ts
: Customized TypeScript compilation logic for Deno.
The C/C++ libdeno middle-end lives here.
api.cc
: libdeno APIs that are exposed and callable from the Rust sidebinding.cc
: code that handles interaction with V8 and where V8 C++ bindings are added. These APIs are exposed Rust and TypeScript side both.snapshot_creator.cc
: logic for creating V8 snapshot during build.
The Rust backend lives here.
libdeno.rs
: exposes libdeno APIs fromlibdeno/api.cc
to Rustisolate.rs
: extracts V8 isolate (an isolated instance of V8 engine) and event loop creation logic using libdeno APIsdeno_dir.rs
: contains logic for Deno module file resolution and cachingops.rs
: where each Deno Op (operation) is handled. This is where the actual file system and network accesses are done.main.rs
: contains main function for Rust. This is the ACTUAL entry point when you run the Deno binary.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.
*.js
or *.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/README.md for more details.
Third party code for Deno. Contains actual node modules, v8, Rust crate code and so on. It is placed in https://github.com/denoland/deno_third_party.
Mostly Python scripts for a range of purposes.
build.py
: Builds Denosetup.py
: Setup and necessary code fetchingformat.py
: Code formattinglint.py
: Code lintingsync_third_party.py
: Sync third_party code after user modifiespackage.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 BUILD.gn
.