# momentjs.com is the Eleventy site that runs the examples in its own docs

> The momentjs.com repository holds the website for the Moment.js library, with the documentation and guides written as Markdown fragments, rendered through Handlebars templates by Eleventy, and with the JavaScript examples in that documentation executed as tests on every change. It is a documentation project rather than a library project, and the pinned moment dependencies are what make those examples trustworthy.

**moment/momentjs.com** — The website for momentjs

- Repository: https://github.com/moment/momentjs.com
- Website: https://momentjs.com
- Stars: 641 · Forks: 801
- Language: JavaScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/moment-momentjs-com

## The website repository, not the library

This repository contains the source for momentjs.com, including the Moment.js and Moment Timezone documentation, guides, downloads and release files.

That list is the first thing to get right, because the name of the organisation and the project invites a different assumption. The moment organisation publishes the Moment.js library itself, and the library lives elsewhere. What sits here is the site that documents it.

The audience is a mix of two groups. The first is the developer looking for how to format a date, who lands on the site and reads the documentation, the guides and the release notes. The second is the contributor who wants to correct an example, add a note or publish an announcement. The repository is built for the second group, and the pull request target is the master branch, with website updates deployed automatically when a pull request is merged.

The last push was on 2026-10-17, and the repository publishes no GitHub releases, which is consistent with what it is. A documentation site has no versioned artefacts to release; it has deployments. The licence is MIT, and the copyright of the site content is therefore permissive in the same way the library's documentation is.

## Markdown in, Handlebars templates, static output

The architecture section of the README describes the build in one paragraph, and it is a small, conventional static site pipeline.

The site is statically generated with Eleventy. Handlebars templates in the pages/ directory render the documentation and guides from Markdown fragments in docs/ and guides/, and also render dated News announcements from the news/ directory. Styles and browser scripts are built from assets/, and the complete site is written to build/.

The split is the interesting part. Content is separated from layout, so a documentation page is a Markdown fragment and a page shell is a Handlebars template, and a News entry is a dated Markdown file rather than a hand-edited HTML page. That means adding a documentation section does not mean touching a template, and it means the same content can be reused in a page and in a listing without duplicating it.

The tooling matches that stack. The package is built with Eleventy 3, with the Handlebars plugin, gray-matter for front matter, handlebars itself, markdown-it for Markdown parsing, and a styling chain of postcss with autoprefixer and sass. The site configuration lives in eleventy.config.js, and the build scripts clean the output directory with a node script before running Eleventy.

The repository is a pnpm workspace, with a pnpm-workspace.yaml alongside the lockfile, and the build output is written into build/ which is not part of the published repository.

## Documentation examples are executed, not trusted

This is the detail that separates this site from most documentation repositories, and it is the strongest argument for how the project is set up.

The serve command automatically tests the JavaScript examples embedded in the Markdown documentation and announcements when the server starts and whenever that content changes. The same checks can be run once without starting the server:

```sh
pnpm doctest
```

The script behind it is a node test run with a custom reporter, scripts/doctest.js with the reporter at scripts/doctest-reporter.js, so the output is shaped for the examples rather than for unit test names.

There is an escape hatch, and its semantics are precise. Examples preceded by a skip-example comment are counted but not run, and the reason given is that those are tool-specific examples or incomplete fragments that need an external runtime, configuration or data to execute. Counting them without running them means the skip is visible in the totals rather than being invisible in the source, so a growing number of skipped examples is a signal rather than a silent drift.

The consequence for a contributor is concrete. If you add a documentation example that does not work, the build tells you. Since the examples are the thing a reader copies into their own code, testing them is the only way the documentation can claim to be correct rather than merely plausible.

## Running the site locally needs Node 24 and pnpm 11

Local development requires Git, Node.js 24 and pnpm 11, and the package metadata is specific about the versions. The engines field requires Node greater than or equal to 24.15.0, and the packageManager field pins pnpm at 11.22.0, which means the repository expects the package manager version to be respected rather than guessed.

Installation and the development server are two commands:

```sh
pnpm install
pnpm serve
```

The site is then available at http://localhost:8080 and reloads when templates, documentation, styles or scripts change. The serve script first cleans the output directory and then runs Eleventy in serve mode, so what you see locally is built the same way the deployed site is built.

The formatting and linting side is equally scripted. Prettier writes the files, a check mode verifies them, and the lint script runs the format check and then markdownlint-cli2 over the Markdown. There is a markdownlint configuration file and a Prettier configuration in the repository root, and a .prettierignore alongside them.

For a site built almost entirely out of Markdown, having the Markdown linted in continuous integration rather than reviewed by eye is a sensible piece of engineering, and it is the kind of thing that shows up as a failing check on a pull request rather than as an inconsistency that survives for years.

## Pinned moment packages supply the runtime for the examples

Moment and Moment Timezone are pinned npm dependencies in this repository, and the README is explicit about why. Their packages provide the release files, the locale data and the runtime used by the documentation tests.

That third role is the important one. The examples in the documentation are executed against the installed library, so the version of Moment that a reader sees documented is the version the site tested. A pinned dependency is what makes that claim true.

Updating them is a deliberate two step process. Both packages are updated to the desired release versions, for example:

```sh
pnpm add --save-dev --save-exact moment@2.30.1 moment-timezone@0.6.3
```

The exact flag matters here, because the versions are pinned on purpose rather than resolved by a range. The resulting package.json and pnpm-lock.yaml changes are then committed.

There is a small inconsistency worth flagging for anyone following the documentation literally. The example command in the README pins moment at 2.30.1 and moment-timezone at 0.6.3, while the current package metadata lists moment at 2.31.0 and moment-timezone at 0.6.5. The example is an illustration of the command to run, not the current state of the dependency.

The dependencies also appear in the devDependencies block, since they exist to support the site and its tests rather than to be consumed by it. The package itself is marked private, which is consistent with a site repository that is never published to a registry.

## Repository layout and deployment

The tree explains the structure of the site and of the contribution process.

Content lives in docs/ for the documentation, guides/ for the guides, news/ for the dated announcements, pages/ for the Handlebars templates, assets/ for styles and browser scripts, and data/ for data the templates consume. Configuration and automation sit at the root or in scripts/, which holds clean.js and the doctest scripts.

Two root files have a specific job. CNAME holds the custom domain for the GitHub Pages deployment, and AGENTS.md is present for coding agents working in the repository, alongside the .github directory that holds the workflows.

Deployment is continuous. Pull requests are made against master, and website updates are deployed automatically when a pull request is merged. There is no release process to wait on and no version to bump, which is the right shape for a site whose content is the product.

The build commands are all in the package metadata, and they show the small size of the toolchain: build cleans and then runs Eleventy, format writes with Prettier, format-check verifies, and lint runs the format check followed by the Markdown lint. The dependency set is correspondingly modest, with no framework beyond Eleventy and the Handlebars plugin, and the styling handled by postcss, autoprefixer and sass.

Because the repository publishes no GitHub releases and deploys on merge, the record of what changed lives in the commit history of the master branch rather than in a changelog of versions.

## Conclusion

momentjs.com suits a contributor who wants to fix a Moment.js documentation page and have the change deployed by opening a pull request, and it is the wrong repository for changing the library itself, since the moment and moment-timezone packages are pinned dependencies here rather than source. Before contributing, run pnpm doctest locally, because the same checks that run in continuous integration will run against your example changes, and remember the site requires Node.js 24 and pnpm 11.

## FAQ

### What is the momentjs.com repository?

It is the source for the momentjs.com website, including the Moment.js and Moment Timezone documentation, guides, downloads and release files. The library itself is not developed in this repository.

### How do I run the Moment.js documentation site locally?

You need Git, Node.js 24 and pnpm 11, with the package requiring Node 24.15.0 or newer and pnpm 11.22.0. Run pnpm install and then pnpm serve, and the site is available at http://localhost:8080 with reloading on changes.

### Are the code examples in the Moment.js documentation tested?

Yes. The serve command automatically tests the JavaScript examples embedded in the Markdown documentation and announcements when the server starts and whenever that content changes, and pnpm doctest runs the same checks once without starting the server. Examples marked with a skip-example comment are counted but not run.

### How are the moment and moment-timezone versions updated on the site?

Both are pinned dev dependencies. You update them with an exact-version command such as pnpm add --save-dev --save-exact moment@2.30.1 moment-timezone@0.6.3 and then commit the resulting package.json and pnpm-lock.yaml changes.

### How do I contribute a documentation change?

Open a pull request against the master branch. Website updates are deployed automatically once a pull request is merged, and the repository runs Prettier checks and markdownlint over the Markdown as part of its lint script.

## Sources

- [Issues](https://github.com/moment/momentjs.com/issues)
- [License: MIT](https://github.com/moment/momentjs.com/blob/master/LICENSE)
- [moment/momentjs.com on GitHub](https://github.com/moment/momentjs.com)
- [Project website](https://momentjs.com)
- [README](https://github.com/moment/momentjs.com/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/moment-momentjs-com