DOCSEARCHbyAlgolia
Submit Docs

Node.js Website Documentation

repository·main·Indexed 27 days ago

https://github.com/nodejs/nodejs.org

Source code and development guides for the official Node.js website (nodejs.org). This Next.js application manages documentation, downloads, and runtime information. Includes documentation for the @node-core/remark-lint plugin for enforcing Markdown standards, UI component libraries, and guides for site configuration, static route generation, and Cloudflare deployment.

Tokens
116.3K
Snippets
171
Records
1.1K
Agent score
92%

What's inside nodejs.org

  1. Overview of ldapjs

    main

    ldapjs is a Node.js implementation of the LDAP protocol designed to address common issues in traditional LDAP deployments. It is built to be connection-oriented and asynchronous, leveraging the Node.js event-driven model.

    Key characteristics:

    • Asynchronous: Designed for high concurrency using Node.js.
    • JavaScript-native: Uses pure JavaScript objects for interaction, reducing the need for developers to manage ASN.1 (the binary wire protocol) or deep RFC details manually.
    • High RFC Coverage: Implements approximately 95% of the core LDAP RFC.
    • Familiar API: Follows a paradigm similar to Express.js.

  2. Overview of the Node.js Website Tech Stack

    main
    The Node.js website (nodejs.org) has transitioned from a Metalsmith and Handlebars-based architecture to a modern stack centered around Next.js and React. This allows for a hybrid approach: the site is statically built for performance and hosting independence, while leveraging Incremental Static Regeneration (ISR) to handle dynamic content like new releases. The site uses MDX for content authoring and Tailwind CSS (utilizing design tokens) for styling.

  3. Overview of Node.js testing and quality strategies

    main

    Node.js employs multiple layers of automation and testing to maintain quality while allowing rapid change:

    • Functional Tests: The first line of defense, requiring test cases for all new features. Code coverage is measured nightly and published at https://coverage.nodejs.org/.
    • Module Testing: Validates that changes do not break popular ecosystem modules. This is managed via https://github.com/nodejs/citgm/.
    • Dependency Testing: Specifically includes nightly V8 tests run within the Node.js repo to ensure changes to the V8 engine do not have negative effects.
    • Platform/OS Coverage: Testing across a broad range of platforms and operating systems to uncover environment-specific issues.
    • Stress Testing: (Future priority) Running scenarios over prolonged periods to find long-running issues.
    • Development Workflows & Use Case Testing: (Future priorities) Testing common developer workflows and specific Node.js use cases.

  4. Understand partner display and randomization logic

    main

    Partner visibility varies by page and is governed by a randomization algorithm:

    • Home Page: Displays all partners. Order is determined by the weight field and a time-based seed that refreshes every 5 minutes.
    • Partners Page: Organizes partners by category (alphabetically within categories). Includes Supporters (OpenCollective/GitHub Sponsors), who are not shown on the Home or Downloads pages.
    • Downloads Section: Only displays partners with the infrastructure category. Uses the same weight-based randomization as the homepage.

    Note: Randomization and rendering are performed on the client side, not during server-side rendering (SSR).

  5. Understand the risks of implicit Domain behavior

    main

    The domain module can exhibit implicit and unobservable behavior that allows one module to intercept exceptions from unrelated code in a different module.

    Key risks include:

    • Exception Swallowing: Calling domain.enter() without an error handler can cause exceptions to be swallowed silently, preventing the originator from knowing an error occurred.
    • Automatic Error Routing: Domains automatically route errors if no 'error' handler is set on an EventEmitter. This propagates across the entire asynchronous chain and can hijack errors unexpectedly.
    • Inconsistent Bubbling: Nested domains may or may not bubble exceptions up the stack depending on timing (e.g., whether an error is thrown immediately or inside a setImmediate callback), leading to difficult-to-debug behavior.

  6. Navigate the Repository Structure

    main

    The repository is organized as a multi-package workspace:

    • apps/site/: The main website application.
      • components/: Website-specific React components.
      • layouts/: Page layout templates.
      • pages/: Content pages (Markdown/MDX) organized by locale (e.g., en/, {locale}/).
      • public/: Static assets (images, documents).
      • next-data/: Build-time data fetching.
      • snippets/: Code snippets for the download page.
      • tests/e2e/: End-to-end tests.
    • packages/:
      • ui-components/: Reusable UI components and Storybook config.
      • i18n/: Internationalization logic and locale configuration.
      • rehype-shiki/: Syntax highlighting plugin.
    nodejs.org/
├── apps/
│   └── site/
│       ├── components/
│       ├── layouts/
│       ├── pages/
│       │   ├── en/
│       │   └── {locale}/
│       ├── public/
│       │       └── static/
│       ├── hooks/
│       ├── providers/
│       ├── types/
│       ├── next-data/
│       ├── scripts/
│       ├── snippets/
│       └── tests/
│           └── e2e/
└── packages/
    ├── ui-components/
    ├── i18n/
    └── rehype-shiki/

  7. Module customization via module.registerHooks() and module.register()

    main

    Node.js is evolving its module loading capabilities. The current direction involves using module.registerHooks() for low-level module loader hooks. To simplify this, module.register() is planned as a helper on top of module.registerHooks() to provide out-of-the-box worker orchestration and compatibility with older APIs.

    For developers needing to run asynchronous code within module.registerHooks(), it is suggested to use a utility similar to everysync. Additionally, an upcoming evaluate hook is being developed to assist module customizers, though it may not cover all evaluation edges due to JavaScript specification constraints.

  8. Security Notice: Node.js Test CI Incident

    main

    A security incident involving the Node.js test CI infrastructure was disclosed in March 2025. The vulnerability allowed for potential code execution on Jenkins agents via a Time-of-Check-Time-of-Use (TOCTOU) exploit during pull request CI builds.

    Impact on Users: There was no impact on the Node.js runtime. There is no risk to users of Node.js, and no action is required by Node.js users.

  12. Understand the Node.js

    main

    Starting with Node.js v0.10, a new streaming implementation (nicknamed "streams2") was introduced to address limitations in the original Stream API. Key improvements include:

    • Controlled Consumption: Readable streams now have a read() method that returns a buffer or null, allowing for precise control over data consumption.
    • Reliable Flow Control: The pause() and resume() methods are now guaranteed rather than advisory.
    • Predictable Events: 'data' events no longer emit immediately upon stream creation; streams start in a paused state and must be read from or resumed to begin emitting data.

    WARNING: If you do not add a 'data' event handler or call resume(), the stream will remain in a paused state indefinitely and will never emit the 'end' event.