CLI tool
mdn/express-locallibrary-tutorial avatar
mdn/express-locallibrary-tutorial

express-locallibrary-tutorial: the MDN library app as a runnable Express codebase

Local Library website written in NodeJS/Express; example for the MDN server-side development NodeJS module: https://developer.mozilla.org/en-US/docs/Learn/Server-side/Express_Nodejs.

1,275 stars841 forksJavaScriptCC0-1.0

At a glance

What is it?
express-locallibrary-tutorial is the reference implementation behind MDN's Local Library server-side tutorial, an Express and Mongoose app with a layered structure, Pug views and a test suite. It suits a learner who wants to read a complete server-side Node example, and the repository's own rule that changes must be synchronised with the tutorial is the constraint that shapes its use.
Who is it for?
express-locallibrary-tutorial fits a developer learning server-side Node who wants a complete, runnable example rather than a fragment, because the application is small enough to read in an afternoon and structured in the layers the tutorial teaches, with routes, controllers, models, a Mongoose schema and a Pug view layer.
Can I use it commercially?
Yes. CC0-1.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 20 days ago.
What is it written in?
Mainly JavaScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 21, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The app is the tutorial's companion code

express-locallibrary-tutorial is the tutorial Local Library website written in Node and Express, and the project description calls it an example for the MDN server-side development NodeJS module.

The application itself is small and specific. It creates an online catalog for a small local library, where users can browse available books and manage their accounts. That scope is chosen deliberately. A library catalog has authors, books, book instances, branches and patrons, which is enough to exercise the ideas a tutorial needs to teach, and small enough that a reader can hold the whole data model in their head.

The repository carries a UML diagram of the database entities, which is the fastest way to understand the model before reading any code, and it links to the associated MDN tutorial home page for the prose that goes with it.

The important structural fact is in the contributing section. The project is the result of carefully running through all the steps in the tutorial on MDN, and any changes to either MDN or this project must be synchronized. Generally it is better to implement changes here before submitting them to MDN.

That rule tells you what this repository is. It is the executable half of a two-part artefact, and the prose half is the tutorial. A change to the code that is not reflected in the tutorial leaves the pair inconsistent, and the direction of work is code first, documentation second. So if you are learning from the tutorial, this repository is where you look to see what the finished version of each step looks like, and if you are improving the tutorial, this is where you make the change first.

The project is CC0 licensed, the last push was on 2026-10-03, and the repository is not archived.

The layered structure, and what each directory is for

The top level of the repository shows the shape of an Express application that follows the standard Express generator layout, with a couple of additions.

There is `app.js`, which is where the Express application is configured, and a `bin/www` script that starts the server, which is where the port is bound and the HTTP server is created. That split is the classic Express layout and it has a good reason, because it separates the app from the server so the app can be imported by a test without binding a port.

There is a `routes/` directory, a `controllers/` directory and a `models/` directory. That is the layering the tutorial teaches, with the route handling the URL and the parameters, the controller holding the business logic, and the model owning the data. The `views/` directory holds the Pug templates, and `public/` holds the static assets, including the images directory that the UML diagram comes from.

Two files at the top level are the ones a tutorial project needs and a demo does not. `populatedb.js` is a script that fills the database with sample data, which is what makes the app browsable the moment you start it rather than an empty catalog. And the `test/` directory holds the test suite, with `supertest` as the dev dependency that drives HTTP-level tests against the app.

There is also a `bin/` directory, a `.prettierrc.json` for formatting, an `.editorconfig`, a `CONTRIBUTING.md`, a `REVIEWING.md` and a `SECURITY.md`.

The `REVIEWING.md` file is worth a note. In a repository where the documentation and the code must stay in step, a file about how changes get reviewed is the mechanism that keeps the two from drifting, and the existence of one suggests the pair is taken seriously enough to need a process around it.

The dependency list, and what each choice teaches

The package manifest is a short curriculum in itself, and the dependencies are chosen for what they demonstrate.

`express` at `^5.1.0` is the framework itself, and the major version matters, because Express 5 changed how errors flow and how unmatched routes are handled compared with Express 4. `mongoose` at `^9.2.1` is the MongoDB object modelling layer, and the schema files in `models/` are where the entity relationships from that UML diagram become code.

`pug` at `^3.0.3` is the template engine for the views, and it is the default choice for the Express generator, so the views directory contains Pug files rather than the EJS or Handlebars alternatives.

The middleware list is the more instructive part. `compression` handles gzip, `cookie-parser` reads cookies, `morgan` writes the request log, and `debug` provides the namespaced debug output that the `DEBUG` environment variable in the run commands switches on. `http-errors` is the library for creating HTTP error objects with a status code, which is the correct way to signal a 404 or a 400 in an Express route.

Three of them are security-relevant and worth calling out. `helmet` at `^8.1.0` sets the standard security headers on every response. `express-rate-limit` at `^7.5.1` throttles requests by client, which is the standard protection for a form endpoint that accepts logins. And `express-validator` at `^7.3.1` validates and sanitises request input, which is what stops malformed data reaching the model layer.

`luxon` at `^3.6.1` is the date and time library, and the presence of a deliberate date library rather than the built-in `Date` is the kind of detail a tutorial should get right, because date handling in a lending application is where the timezone bugs live.

The dev dependencies are instructive too. `nodemon` restarts the server on change and backs the `devstart` script. `supertest` drives the tests over HTTP. And `mongodb-memory-server` at `^10.1.4` is the interesting one, because it spins up a real MongoDB in memory for the test run, which means the tests do not need a database server and do not share state with the development database.

Running it, and the database caveat

The quick start is four steps and it works the same way on every platform apart from how you set the environment variable.

First, set up a Node.js development environment, which the project links to the MDN guide for. Then, in the root of the clone, install the project:

bash
npm install

Then run the tutorial server, using the appropriate command line shell for your environment:

bash
# Linux terminal
DEBUG=express-locallibrary-tutorial:* npm run devstart

# Windows Powershell
$ENV:DEBUG = "express-locallibrary-tutorial:*"; npm start

And open a browser to http://localhost:3000/ to open the library site.

The two shell forms are the interesting detail. The debug namespace is the same in both, `express-locallibrary-tutorial:*`, but the syntax for setting an environment variable differs between a POSIX shell and PowerShell, and the Linux form uses `npm run devstart` while the Windows form uses `npm start`. The manifest explains why, since `devstart` is `nodemon./bin/www` and `start` is `node./bin/www`, and `serverstart` is the same thing as the Linux form with the `DEBUG` prefix built into the script. So `npm run serverstart` carries the `DEBUG` prefix itself, which is the version to prefer in a POSIX shell.

The `engines` field requires Node `>=22.0.0`, and the package is marked private, so it is not published to npm. It is an application, not a library.

The database caveat is the one thing to read carefully. The library uses a default MongoDB database hosted on MongoDB Atlas, and you should use a different database for your own code experiments. That is a sensible instruction, since a shared tutorial database is both a reliability problem and a privacy question, and it is the kind of thing that would otherwise be discovered the hard way.

The auth branch, and where this project stops

There is one branch that is worth knowing about, and the project flags it in a way that tells you its status without you having to read the code.

The auth branch implements an unsupported and undocumented version of the library with user authentication and authorization. The documentation says it may be a useful starting point for some users.

Unsupported and undocumented, but useful, is an honest description of a prototype. The main branch is the version that matches the tutorial, and the tutorial does not cover authentication. So the branch is the place to look if you want to see how a login flow might be bolted onto this application, and it is the place not to look if you want something you can copy into production, because nothing about it is committed to and nothing about it is written down.

The tests are the other thing to know about. Before submitting a pull request, make sure the tests pass, and the command is:

bash
npm test

which runs `node --test`, the built-in Node test runner, rather than a separate framework. Combined with supertest, that means the tests exercise the Express app over HTTP without a separate test framework dependency, which keeps the dev dependency list short.

Where this project stops is in the scope of the application, and it stops cleanly. It is a catalog and a set of accounts. It does not have a borrowing workflow, a fine calculation, a reservation system or a search index. If you are looking for a library management system to deploy, this is not one, and the tutorial is structured so that adding those features is the exercise.

The alternative approaches are worth naming. The MDN tutorial on its own teaches the same material in prose, and for a reader who wants the concepts rather than the code, the prose is faster. A more complete open source library system would give you borrowing and circulation out of the box, at the cost of a schema and a workflow that does not match what the tutorial teaches. And building the same structure yourself from the Express generator and applying the patterns in this repository gives you the same result with your own domain model, which is the point the tutorial is making in the first place.

Editorial conclusion

express-locallibrary-tutorial fits a developer learning server-side Node who wants a complete, runnable example rather than a fragment, because the application is small enough to read in an afternoon and structured in the layers the tutorial teaches, with routes, controllers, models, a Mongoose schema and a Pug view layer. Skip it if you want a framework to build on, since it is a tutorial artefact, and note the synchronisation rule, because any change to the documentation must match a change here, and changes generally start here. Before you run it, set up a database of your own, since the project uses a default MongoDB Atlas instance and the documentation tells you to use a different database for your own experiments. The last push was on 2026-10-03.

Frequently asked questions

What is express-locallibrary-tutorial?

It is the tutorial Local Library website written in Node and Express, an online catalog for a small library where users browse books and manage their accounts, and it is the reference implementation for MDN's server-side development tutorial.

How do I run the express-locallibrary-tutorial app locally?

Set up a Node.js environment, run `npm install` in the clone, then start the server with `DEBUG=express-locallibrary-tutorial:* npm run devstart` on Linux or `$ENV:DEBUG = "express-locallibrary-tutorial:*"; npm start` in PowerShell, and open http://localhost:3000/.

Which database does the local library tutorial use?

It uses a default MongoDB database hosted on MongoDB Atlas, and the documentation tells you to use a different database for your own code experiments. The model layer is Mongoose and the dev dependencies include mongodb-memory-server for the test suite.

What does the auth branch of express-locallibrary-tutorial contain?

It implements an unsupported and undocumented version of the library with user authentication and authorization, and the documentation describes it as possibly a useful starting point for some users.

How do the tests run in express-locallibrary-tutorial?

With `npm test`, which runs `node --test`, the built-in Node test runner, driving the Express app over HTTP with supertest. The project requires Node 22.0.0 or newer and is marked private.

Official sources

  1. Issues
  2. License: CC0-1.0
  3. mdn/express-locallibrary-tutorial on GitHub
  4. README
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/mdn-express-locallibrary-tutorial.svg)](https://hysenlabs.com/projects/mdn-express-locallibrary-tutorial)