firebase/quickstart-js: what the sample collection actually contains

What firebase/quickstart-js is, and who it is written for

The repository is a collection of quickstart samples demonstrating the Firebase APIs through the JavaScript SDK. That sentence from the README sets the scope precisely: these are demonstrations, not an SDK, not a framework, and not a template generator. Each sample lives in its own subdirectory with its own README describing how to get started.

The audience is a web developer who has decided to use Firebase and now needs to see a concrete call sequence for a specific feature. The Auth directory alone covers anonymous auth, custom auth, email and password, email link, three phone auth variants (visible reCAPTCHA, invisible reCAPTCHA, popup), Google, Facebook, Twitter, Microsoft and GitHub sign-in through popup and redirect, a Chrome extension variant of Google auth, and multi-factor authentication with SMS. That last one is flagged in the README as currently only available for Google Cloud Identity Platform projects, which is the kind of constraint a sample README can state but a general tutorial usually omits.

If you are evaluating Firebase as a platform, this repository will not help you decide. It shows how to call APIs, not whether you should use them. The value is concentrated in the moment after the decision, when you need to know which function to call and in what order.

How the samples are organized and what the build tooling does

The top level is a monorepo managed with Lerna. The root package.json declares lerna as a devDependency and exposes two scripts: bootstrap, which runs lerna bootstrap, and test, which runs scripts/test.sh. The repository layout confirms this with lerna.json at the root alongside package-lock.json.

The engines field is unusually specific. It requires npm greater than or equal to 9.0.0 and less than 10.0.0, and Node greater than or equal to 18.0.0 and less than or equal to 20.0.0. Both are hard ranges with an upper bound. If you are on Node 22 or npm 10, the root package.json says your environment is outside the supported window, and you should expect that before you start debugging anything else.

The runtime dependencies at the root are @firebase/ai and firebase. The presence of @firebase/ai alongside the ai/ directory in the repository layout indicates that the collection has grown beyond the classic Auth, Database, Firestore, Functions, Storage and Messaging set listed in the README. The README's own list does not mention ai/, dataconnect/ or remote-config/, even though those directories exist at the top level. That gap is worth knowing: the README is the entry point, but the directory listing is the more current inventory of what is present.

Installing the repository and running one sample

The README points to firebase.google.com/docs/web/setup for general setup and defers per-sample instructions to the README.md inside each subdirectory. It does not give a single top-level install command in the text reproduced here. What the repository files do give is the tooling: Lerna at the root with a bootstrap script.

Start by cloning the repository, then install and link the workspace packages from the root:

npm install
npm run bootstrap

The second command runs lerna bootstrap, which installs dependencies across the sample directories and links any cross-references between them. After that, the README instructs you to open the README.md in the subdirectory for the sample you want, for example auth/README.md or firestore/README.md, and follow the steps there. Those steps are where the Firebase project configuration belongs, and they are not reproduced at the root.

The repository also ships a test entry point. Running it from the root executes the shell script the project uses in CI:

npm test

That invokes scripts/test.sh. If you are trying to understand whether your local environment matches what the maintainers run, that script is the definition of it, not the prose in the README. The README shows a CI Tests badge linked to the repository's GitHub Actions workflow, so the same script is what the badge reports on.

The samples are minimal by design, and that is a real limitation

A quickstart sample has to fit on a screen. That constraint shapes everything about this repository, and it is the source of most of its weaknesses as a learning resource.

The Auth directory is the clearest example. It offers popup and redirect flows for Google, Facebook, Twitter, Microsoft and GitHub, which is genuinely useful coverage of the branching. What it does not offer, according to the README's own list, is anything about token refresh strategy, session persistence trade-offs, or what happens when a popup is blocked. Those are the problems that consume real time in production, and a sample that demonstrates the happy path cannot address them.

The same applies to the data samples. Database contains a simple social blogging app and Firestore contains a simple rating app. Both are named as simple in the README, and that naming is honest. A rating app shows you how to write a document and read it back. It does not show you how to structure collections for a query pattern you have not written yet, and Firestore data modeling is exactly the kind of decision that is expensive to reverse.

There is also a maintenance question. The last push to the repository was on 2026-09-22, so the code is current. But a sample collection ages differently from a library: the code can be correct and still teach an outdated idiom if the SDK's recommended patterns move on. When you copy a snippet, check it against the current SDK documentation rather than assuming the sample reflects the latest guidance.

Where this fits against a full starter template

The obvious alternative is a framework starter that ships Firebase integration already wired, such as a Next.js or React template with authentication and a database layer configured. The difference in approach is about what is pre-decided.

A starter template makes architectural choices for you: routing, state management, where the auth context lives, how server and client components split. You get a running application faster, and you inherit decisions you did not make. firebase/quickstart-js makes almost no choices. Each subdirectory is a narrow demonstration of one API surface, and there is no application shell tying them together. You read the sample, understand the call, and place it wherever your own architecture says it belongs.

That makes the repository better for a developer who already has an application and needs to add one Firebase capability to it. It makes it worse for someone starting from nothing, because assembling the samples into a coherent app is work the repository does not do for you. The multi-factor authentication sample illustrates the split well: it is available only for Google Cloud Identity Platform projects per the README, so if you are on a plain Firebase project, the sample is not a shortcut, it is a pointer to a different product.

Licence terms and what they mean for reuse

The repository is licensed under Apache-2.0, stated in both the README and the package.json license field. Apache-2.0 is a permissive licence that allows use, modification and redistribution, including in commercial and closed-source projects, provided the licence terms are met. It also includes an explicit patent grant, which distinguishes it from a plain MIT licence.

The practical implication for a sample collection is that copying a snippet into your own codebase is within the terms. The obligation that matters is attribution and notice preservation: Apache-2.0 requires that you retain copyright notices and include a copy of the licence. In practice, a file that began as a sample and was pasted into a larger project should carry a note about its origin.

This is not legal advice, and the specifics of notice placement depend on how your project is distributed. If you are copying more than a snippet, or redistributing a modified version of a sample, read the LICENSE file in the repository and the Apache-2.0 text itself rather than relying on a summary. The CONTRIBUTING.md file governs contributions back to the project, which is a separate concern from consuming it.

What to check before you adapt a sample

Three things determine whether a sample will work in your environment, and all three are visible in the repository files.

First, the runtime. The root package.json restricts Node to 18 through 20 and npm to the 9.x line. Confirm your version before installing, because the failure mode for an out-of-range runtime is often an install or build error that looks unrelated to the actual cause.

Second, the service configuration. The README's Auth list notes that multi-factor authentication with SMS is only available for Google Cloud Identity Platform projects. That is one documented case, but the general pattern holds across the collection: a sample assumes the corresponding service or provider is already enabled in your Firebase project. The README does not document what happens when it is not, so treat console configuration as a prerequisite you verify yourself.

Third, the sample's own README. The root README explicitly says samples include README.md files with instructions for getting started, and it does not reproduce those instructions. The per-directory README is where the actual setup steps live. Reading the root README alone tells you what exists; it does not tell you how to run any of it.

Editorial conclusion

Use firebase/quickstart-js when you need a working reference for one specific Firebase Web API and want to read the source before writing your own integration. Do not use it as a dependency, a starter template you intend to ship, or a source of production hardening advice, because the samples are deliberately minimal and the root package.json pins npm to the 9.x major line. Before adapting anything, check the README inside the subdirectory you care about, confirm your Node version falls inside the engines range, and verify your own Firebase project has the provider or service enabled, since a sample will fail at runtime rather than explain the missing console configuration.

Frequently asked questions

Official sources

1. firebase/quickstart-js on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README