update

docs/contribute/formatter.md

@@ -4,3 +4,6 @@ title: Formatter
 ---
 
 # Formatter
+
+While [prettier] has established itself as the de facto code formatter for JavaScript, there is a significant demand in the developer community for a less opinionated alternative. Recognizing this need, our ambition is to undertake research and development to create a new JavaScript formatter that offers increased flexibility and customization options.
+Unfortunately we are currently lacking the resources to do so.

docs/contribute/minifier.md

@@ -4,3 +4,17 @@ title: Minifier
 ---
 
 # Minifier
+
+JavaScript minification plays a crucial role in optimizing website performance as it reduces the amount of data sent to users,
+resulting in faster page loads.
+This holds tremendous economic value, particularly for e-commerce websites, where every second can equate to millions of dollars.
+
+However, existing minifiers typically require a trade-off between compression quality and speed.
+You have to choose between the slowest for the best compression or the fastest for less compression.
+But what if we could develop a faster minifier without compromising on compression?
+
+We are actively working on a prototype that aims to achieve this goal,
+by porting all test cases from well-known minifiers such as [google-closure-compiler], [terser], [esbuild], and [tdewolff-minify].
+
+Preliminary results indicate that we are on track to achieve our objectives.
+With the Oxc minifier, you can expect faster minification times without sacrificing compression quality.

docs/contribute/parser.md

@@ -5,6 +5,8 @@ title: Parser
 
 # Parser
 
+We aim to be the fastest Rust-based ready-for-production parser.
+
 ## Conformance Tests
 
 ```bash

docs/contribute/performance.md

@@ -5,7 +5,19 @@ title: Performance
 
 # Performance Tuning
 
-## Mac Xcode Instruments
+## Compile Time
+
+While Rust has gained a reputation for its comparatively slower compilation speed,
+we have dedicated significant effort to fine-tune the Rust compilation speed.
+Our aim is to minimize any impact on your development workflow,
+ensuring that developing your own Oxc based tools remains a smooth and efficient experience.
+
+This is demonstrated by our [CI runs](https://github.com/web-infra-dev/oxc/actions/workflows/ci.yml?query=branch%3Amain),
+where warm runs complete in 5 minutes.
+
+## Profile
+
+### Mac Xcode Instruments
 
 Mac Xcode instruments can be used to produce a CPU profile.
 

docs/contribute/resolver.md

@@ -4,3 +4,8 @@ title: Resolver
 ---
 
 # Resolver
+
+Module resolution plays a crucial role in JavaScript tooling, especially for tasks like multi-file analysis or bundling. However, it can often become a performance bottleneck.
+To address this, we are actively working on porting [enhanced-resolve].
+
+[eslint-plugin-import] will be our first application for the resolver, since it is currently a performance and complexity blocker for a lot of projects.

docs/contribute/rules.md

@@ -3,6 +3,13 @@ id: rules
 title: Rules
 ---
 
+- Check out some of the [good first issues](https://github.com/web-infra-dev/oxc/contribute) or ask us on [Discord][discord-url].
 - We welcome any form of contributions
 - We prefer smaller PRs to get things merged quickly
 - We recommend submitting stacked PRs via https://graphite.dev
+- APIs should be simple and well-documented.
+- All performance issues (runtime and compilation speed) are considered as bugs in this project.
+- Third-party dependencies should be minimal.
+- Monitor code coverage for unused code. Aim for 99% code coverage.
+- Embrace data-oriented design.
+- Prefer smaller PRs. Try [graphite.dev](https://graphite.dev).

docs/contribute/transformer.md

@@ -4,3 +4,6 @@ title: Transformer
 ---
 
 # Transformer
+
+A transformer is responsible for turning higher versions of ECMAScript to a lower version that can be used in older browsers.
+We are currently focusing on an esnext to es2015 transpiler. See the [umbrella issue](https://github.com/web-infra-dev/oxc/issues/974) for details.

docs/learn/architecture/parser.md

@@ -4,3 +4,26 @@ title: Parser
 ---
 
 # Parser
+
+Oxc maintains its own AST and parser, which is by far the fastest and most conformant JavaScript and TypeScript (including JSX and TSX) parser written in Rust.
+
+As the parser often represents a key performance bottleneck in JavaScript tooling,
+any minor improvements can have a cascading effect on our downstream tools.
+By developing our parser, we have the opportunity to explore and implement well-researched performance techniques.
+
+While many existing JavaScript tools rely on [estree] as their AST specification,
+a notable drawback is its abundance of ambiguous nodes.
+This ambiguity often leads to confusion during development with [estree].
+
+The Oxc AST differs slightly from the [estree] AST by removing ambiguous nodes and introducing distinct types.
+For example, instead of using a generic [estree] `Identifier`,
+the Oxc AST provides specific types such as `BindingIdentifier`, `IdentifierReference`, and `IdentifierName`.
+
+This clear distinction greatly enhances the development experience by aligning more closely with the ECMAScript specification.
+
+## How is it so fast
+
+- AST is allocated in a [memory arena](https://crates.io/crates/bumpalo) for fast AST memory allocation and deallocation
+- Short strings are inlined by [CompactString](https://crates.io/crates/compact_str)
+- No other heap allocations are done except the above two
+- Scope binding, symbol resolution and some syntax errors are not done in the parser, they are delegated to the semantic analyzer

docs/learn/references.md

@@ -3,9 +3,12 @@ id: references
 title: References
 ---
 
----
+## 📚 Learning Resources
 
-## title: References
+- My small tutorial on [how to write a JavaScript Parser in Rust](https://oxc-project.github.io/javascript-parser-in-rust)
+- My small article [Pursuit of Performance on Building a JavaScript Compiler](https://rustmagazine.org/issue-3/javascript-compiler/)
+- [Crafting Interpreters](https://craftinginterpreters.com)
+- [Andrew Kelley - Practical DOD](https://vimeo.com/649009599)
 
 ## Parsers (in active development)
 

docs/usage/linter.md

@@ -7,17 +7,26 @@ title: Linter
 
 ## Features
 
-- Runs 50 -100 times faster than ESLint ([Benchmark](https://github.com/oxc-project/bench-javascript-linter)).
+- Runs 50 -100 times faster than ESLint, , and scales with the number of CPU cores ([Benchmark](https://github.com/oxc-project/bench-javascript-linter)).
 - No configuration is required for default usage
 - Reports errors and useless code by default
+- Convention over configuration
+
+## Adoptions
+
+![npm](https://img.shields.io/npm/dw/oxlint)
+
+- A 5M LOC typescript codebase previously running ESLint parallelized across 48 workers in CI taking 75 mins (12m wall time), it is now 8 seconds on a single worker. ([Source](https://twitter.com/boshen_c/status/1714827365136929029))
 
 ## Usage
 
+Install [oxlint](https://www.npmjs.com/package/oxlint) or via `npx`:
+
 ```bash
 npx oxlint@latest
 ```
 
-You may also use `yarn dlx`, `pnpm dlx`, `bunx` or `deno run` because `oxlint` is published to [npm](https://www.npmjs.com/package/oxlint).
+You may also use `yarn dlx`, `pnpm dlx`, `bunx` or `deno run` because `oxlint` is published to npm.
 
 ### Commands
 

docs/usage/parser.md

@@ -0,0 +1,27 @@
+---
+id: parser
+title: Parser
+---
+
+# Parser
+
+## Features
+
+- 2x faster then swc parser
+- by far the fastest and most conformant JavaScript and TypeScript (including JSX and TSX) parser written in Rust
+
+[Benchmark](https://github.com/oxc-project/bench-javascript-parser-written-in-rust)
+
+## Usage in Rust
+
+- The umbrella crate [oxc][docs-oxc-url] exports all public crates from this repository.
+- The AST and parser crates [oxc_ast][docs-ast-url] and [oxc_parser][docs-parser-url] are production ready.
+
+## Usage in Node
+
+- Via napi: [@oxidation-compiler/napi][npm-napi]
+
+[docs-oxc-url]: https://docs.rs/oxc
+[docs-ast-url]: https://docs.rs/oxc_ast
+[docs-parser-url]: https://docs.rs/oxc_parser
+[npm-napi]: https://www.npmjs.com/package/@oxidation-compiler/napi

docs/usage/resolver.md

@@ -4,3 +4,35 @@ title: Resolver
 ---
 
 # Resolver
+
+Node.js Module Resolution.
+
+- Feature complete
+- All configuration options are aligned with enhanced-resolve
+
+## Rust Usage
+
+- https://docs.rs/oxc_resolver
+- https://crates.io/oxc_resolver
+
+## Example
+
+```rust
+use std::{env, path::PathBuf};
+
+use oxc_resolver::{ResolveOptions, Resolver};
+
+fn main() {
+    let path = env::args().nth(1).expect("require path");
+    let request = env::args().nth(2).expect("require request");
+    let path = PathBuf::from(path).canonicalize().unwrap();
+
+    println!("path: {path:?}");
+    println!("request: {request}");
+
+    match Resolver::new(ResolveOptions::default()).resolve(path, &request) {
+        Err(error) => println!("Error: {error}"),
+        Ok(resolution) => println!("Resolved: {}", resolution.full_path().to_string_lossy()),
+    }
+}
+```

docusaurus.config.ts

@@ -4,7 +4,8 @@ import type * as Preset from '@docusaurus/preset-classic';
 
 const config: Config = {
   title: 'The JavaScript Oxidation Compiler',
-  tagline: 'A collection of JavaScript tooling written in Rust',
+  tagline:
+    'A collection of high-performance JavaScript tooling written in Rust',
   favicon:
     'https://raw.githubusercontent.com/oxc-project/oxc-assets/main/logo-round.png',
   url: 'https://oxc-project.github.io',

sidebars.ts

@@ -1,7 +1,7 @@
 import type { SidebarsConfig } from '@docusaurus/plugin-content-docs';
 
 const sidebars: SidebarsConfig = {
-  usage: ['usage/linter', 'usage/resolver'],
+  usage: ['usage/linter', 'usage/parser', 'usage/resolver'],
   contribute: [
     'contribute/intro',
     'contribute/rules',