stdlib JavaScript Standard Library

The project wraps built-in JavaScript globals as individual packages rather than relying on the environment's native implementation. This approach is used to:

• Polyfill: Ensure consistent behavior across different platforms and environments by providing implementations for absent or defective globals.
• Document: Provide centralized, consistent documentation for globals.
• Test: Monitor built-in implementations for abnormal behavior via unit testing.
• Mock: Facilitate testing by allowing globals to be mocked via dependency injection without side effects from overwriting the global scope.
• Benchmark: Organize and track environment performance for built-ins.

The project does not typically submit improvements to external libraries due to:

• Rewrites: Necessary improvements often require drastic architectural shifts or complete rewrites of existing libraries.
• Bandwidth: Core authors lack the resources to maintain both this project and external community libraries.
• Opportunity cost: Engaging with external libraries involves risks and maintenance burdens that detract from project development.
• Priorities: The project focuses on areas where authors have the most control to avoid developer debates (bikeshedding) and maximize development efficiency.

The stdlib CLI is organized into several functional groups. Common command categories include:

• Commands: help, datasets, repl, repl-presentation.
• Assert: Environment and value assertions (e.g., has-wasm-support, is-email-address).
• Benchmarking: bench (run benchmark files) and timeit (time a snippet).
• Filesystem: exists, read-dir, read-file, write-file, etc.
• Random: Pseudorandom number generators (e.g., random-mt19937, random-randn).
• System: Environment info (e.g., arch, cwd, platform).
• Utilities: String and numeric manipulations (e.g., capitalize, trim, sizeof).

The deps directory is used for managing vendor dependencies (third-party libraries). It is organized into the following subdirectories:

• deps/checksums: Contains checksums for vendor dependencies to ensure integrity.
• deps/test: Contains installation tests for vendor dependencies.
• deps/tmp: A temporary location for storing dependency downloads.
• deps/build: A location for storing dependency builds.

Important: The deps/tmp and deps/build directories should not be committed to the project repository.

The project follows a modular decomposition philosophy. Every package (core library and tooling) is designed to be consumed and understood independently. Each package maintains its own resource locality, including its own documentation, tests, benchmarks, and examples.

Key principles:

• Independence: You should not need to install the entire project to consume a single part.
• Granularity: Unlike traditional standard libraries (e.g., Python, R, Julia) that require bundling the entire runtime, this project allows you to consume only what you need.
• Composability: The architecture is designed to allow users to fork, customize, and recombine individual parts to build their own custom standard libraries.

To avoid phishing attempts, only trust the domain names officially affiliated with the project. The following domains are currently active:

• stdlib.io: The official website.
• stdlib.blog: The official development blog.

The project views WebAssembly (Wasm) as a complementary technology rather than a replacement for JavaScript-based numerical libraries. stdlib focuses on providing modular, bundle-friendly, and idiomatic JavaScript implementations that address immediate needs for:

• Modular Bundling: Unlike large monolithic libraries (e.g., NumPy) that are difficult to tree-shake, stdlib is designed to be modular for efficient web bundling.
• Developer Experience: Providing libraries in the same idiom as the application code reduces cognitive overhead.
• Immediate Availability: Providing working numerical libraries for the web now, rather than waiting for ubiquitous Wasm development patterns.