Contains the bindings to wasm and napi for the objects used on the JavaScript side, thanks to the #[napi] macro.

This code is used in packages/rolldown to generate bindings.

rolldown_common

rolldown_common::file_emitter

The FileEmitter is instanciated and passed as an Arc<FileEmitter> to the rolldown_plugin::PluginDriver

rolldown_css

Tiny wrapper around lightningcss

An extremely fast CSS parser, transformer, bundler, and minifier (built in rust)

📄

rolldown_ecmascript

oxc::allocator::Allocator is needed for the parser - https://github.com/oxc-project/oxc/blob/main/crates/oxc_allocator/src/lib.rs
- Oxc uses a bump-based memory arena for faster AST allocations - (example of bump alocator : bumpalo)

📄

rolldown_fs

Thin abstraction over the traits oxc_resolver::{FileMetadata, FileSystem}.

For the implementation, see oxc-project/oxc-resolver, a Rust version of webpack/enhanced-resolve.

📄

rolldown_loader_utils

json_to_esm
- format!("export const {key} = {};\n", serde_json::to_string_pretty(value)?)
- relies on
  - oxc_syntax::identifier::is_identifier_name to make sure the export is a valid identifier (otherwise, creates a temporary const and export as)
  - oxc_syntax::keyword::is_reserved_keyword_or_global_object
text_to_string_literal
binary_to_esm
- Based on the platform, it will be __toBinary or __toBinaryNode, the implementation is in crates/rolldown/src/runtime
- import { __toBinary } from ./some-module; export default __toBinary(base64encoded)

📄

rolldown_plugin

trait Plugin contains default implementation for the interfaces it declares:
- build_start, resolve_id, load, transform, transform_ast and many more
trait Pluginable
- exposes interfaces without implementations for call_load, call_transform, call_transform_ast, that kinda stuff
- should not be used directly, it is recommended to use the Plugin trait - comment from source code:
  - "The main reason we don't expose this trait is that it used async_trait, which make it rust-analyzer can't provide a good auto-completion experience."
impl<T: Plugin> Pluginable for T block creates implementations for the methods call_* based on Plugin trait implementation

📄

rolldown_plugin::PluginDriver

PluginDriver

instanciated by the BundlerBuilder
- plugins: Vec<SharedPluginable> - list of plugins
- resolver: &Arc<Resolver> - see rolldown_resolver
- file_emitter: SharedFileEmitter - see rolldown_common::file_emitter (source) / rolldown_common::file_emitter
- options= SharedNormalizedBundlerOptions = Arc<NormalizedBundlerOptions>
- watch_files
PluginDriver::iter_plugin_with_context_by_order(self, [PluginIdx]) is available: it loops over plugins, making their context available
- it is used in many methods such as PluginDriver::{build_start,resolve_id,load,transform,transform_ast,module_parsed,build_end,watch_change,close_watcher}
- those implementation are in the files rolldown_plugin::plugin_driver::build_hooks, rolldown_plugin::plugin_driver::output_hooks and rolldown_plugin::plugin_driver::watch_hooks
for each plugin, a PluginContextImpl (something close to a Arc<PluginContext>) is created
- this list of contexts is pushed to PluginDriver::contexts
- each of the contexts share references (as Weak or Arc) to what the PluginDriver is holding, such as resolver, file_emitter, options, watch_files ...

rolldown_resolver

This plugin relies on the traits rolldown_fs::{FileSystem, OsFileSystem} from rolldown_fs which relies on oxc_resolver::{FileMetadata, FileSystem}.

This is the plugin in charge of resolving the paths of the imports, which is a very tricky thing in JavaScript. The resolving part is handled by the oxc_resolver crate (in order to be able to share).

rolldown_resolver::Resolver::new creates an instance of the resolver

based on
- ResolveOptions (handles all the default cases)
- Platform which may be node, browser or neutral
instanciates Resolver::{default_resolver,import_resolver,require_resolver} with oxc_resolver::ResolverGeneric<T> passing the options resolved above

Call site of rolldown_resolver::Resolver::new is in BundlerBuilder, while creating PluginDriver
rolldown_resolver::Resolver::resolve is exposed

it accepts:
- importer: Option<&Path> - the path from where the module to be imported is to be resolved
- specifier: &str - the "name" of the module to resolve
- import_kind: rolldown_common::ImportKind whether it is an import, a dynamic import, a require, an AtImport (css)
it resolve the directory of the importer from importer
calls the adequate resolver (from oxc_resolver) based on import_kind with (importer, specifier)
retrieves the package.json related to the module being resolved, since it can affect how we should resolve it
caches the package.json
calculates the following for the return:
- module_type: rolldown_common::ModuleDefFormat:
  - ending with .mjs or .cjs is easy
  - however, the type field of the package.json may affect the resolution (module, commonjs)

📄

rolldown_rstr

Exposes rolldown_rstr::Rstr which is a thin wrapper over oxc::span::CompactStr, which is a wrapper over the compact_str crate.

A memory efficient string type that can store up to 24* bytes on the stack.

A CompactString is a more memory efficient string type, that can store smaller strings on the stack, and transparently stores longer strings on the heap (aka a small string optimization). It can mostly be used as a drop in replacement for String and are particularly useful in parsing, deserializing, or any other application where you may have smaller strings.

rolldown_rstr::Rstr is used in many places in the project.

📄

rolldown_sourcemap

Exposes collapse_sourcemaps(mut sourcemap_chain: Vec<&SourceMap>) -> SourceMap.

It collapses multiple sourcemaps generated by calls to oxc::oxc_codegen::CodeGen::new().enable_source_map(&filename, &source_text).build() into one giant sourcemap.

Relies on oxc::sourcemap::*.

📄