@nestjs/passport: wiring Passport into a Nest application

A bridge module, and a README that sends you elsewhere for the details

The description section of the README is a single sentence: Passport utilities module for Nest. That is the whole pitch, and it is worth being precise about what it implies. Passport is a separate library with its own strategies, and this module makes it usable inside a Nest application rather than replacing it. The README's own structure reflects that, with the installation section, a quick start section that points at the Nest documentation recipe for Passport, and a support section that talks about Nest rather than about this package. So the module is not documented in its own repository, it is documented as part of the framework's recipes. The repository is small in the way a wrapper should be, with a lib directory for the source, a test directory, and the usual configuration files.

Installing it means installing Passport alongside it

The installation is a single command, and it installs two things.

$ npm i --save @nestjs/passport passport

The reason Passport is in the same command rather than a separate instruction is that the module is a peer of it. The package manifest declares the peer dependencies explicitly, and they are the interesting part of the manifest. The Nest common package is accepted at either the 11 or the 12 major, written as a range covering both. Passport itself is accepted across three generations, from 0.5.0 through 0.6.0 to 0.7.0. That is a deliberate choice for a bridge package. A module that pinned one Passport major would force a lockfile change on every consumer the moment Passport moved, and a module that accepted only the newest would block applications stuck on an older Passport for a good reason. The cost of the wide range is that the module has to tolerate three Passport generations, which is part of why the test suite carries several Passport strategies as dev dependencies.

The package shape, and what the exports map says

The manifest is short and modern. The package is named @nestjs/passport, is an ES module with a type of module, and ships the dist directory as its only published file. The main entry is the built index in dist, the types entry points at the generated declaration file, and the exports map offers the default export alongside the package.json subpath. The build script clears the dist directory and then runs the TypeScript compiler against a separate build configuration, tsconfig.build.json, which is the standard way to keep test-only configuration out of the published output. The version is 12.0.0, and the release history shows 11.0.5 and 11.0.4 in January 2025, so the 12 major is a recent step and the 11 line was where the module sat for a while.

A toolchain that has moved on from the Nest defaults

The scripts section shows a project that has modernised its tooling rather than inherited the Nest defaults. Formatting is prettier over the lib TypeScript files, and linting is done with oxlint rather than eslint, with a matching .oxlintrc.json at the root. The test runner is vitest, with a separate coverage script and a watch mode, and the configuration lives in a vitest.config.ts. The precommit script runs lint-staged, and husky is wired in through the prepare script, so the hooks are installed on install rather than by a separate step. Releases are handled by release-it with a .release-it.json, and there is a .commitlintrc.json using the angular config, which is the commit convention the Nest project itself uses. Dependency updates are automated with renovate.

What the dev dependencies reveal about what the module is tested against

The dev dependencies are the best description of the module's scope, because they are the things the test suite actually exercises. There are three Passport strategies in the list, passport-jwt, passport-local and passport-cookie, which between them cover the common cases of a token strategy, a credential strategy and a session or cookie strategy. There is also reflect-metadata, which Nest requires for its decorator metadata, and the Nest packages themselves at version 12.0.4, including the core, the common, the testing helper, the JWT module and the Express platform, plus rxjs. The test tooling includes vitest with coverage, and Pactum at 3.9.1, which is an HTTP testing library, which tells you the tests drive real requests against a running Nest application rather than only calling module methods in isolation.

The alternative: wiring Passport yourself

The honest comparison is not with a competing module but with the option of not using one. Passport is usable inside a Nest application without this bridge, by registering the strategies yourself and calling the Passport middleware in a middleware or guard, wiring the strategy instances through dependency injection by hand. The difference in approach is what the module removes. The bridge handles the version negotiation between the two libraries, the lifecycle of the underlying Passport instance inside the Nest container, and the fact that strategies are meant to be singletons that Nest would otherwise construct for you. The cost of taking that route is that you own the wiring and the version compatibility, and the cost of using the module is that you accept its peer dependency ranges and its own release cadence, which move separately from Passport's.

A maintained package inside a larger framework project

The project sits inside the Nest organisation, and the README's support section is about Nest as a whole, describing it as an MIT licensed open source project that grows through sponsorship and the support of backers, with a link to the Nest support page. The author is Kamil Mysliwiec, and the README lists the website and the framework's Twitter account. The licence is MIT, stated in the README and in the manifest, and the repository is not archived with the last push on 2026-10-19. The CI configuration is CircleCI, and there is a .node-version file, a .prettierrc, a .npmignore and a tsconfig.json alongside the build configuration. The practical takeaway for an adopter is that this module tracks the Nest major versions rather than standing still, so a Nest upgrade is a moment when you will want to read its release notes.

Editorial conclusion

The Nest Passport module fits a Nest application that has chosen Passport for its authentication strategies and wants the framework's module system, dependency injection and testing conventions rather than hand-wired middleware. It does not fit a team that has moved to a different authentication approach, since this module exists to make Passport fit Nest rather than to recommend Passport. Verify first that your Passport version falls inside the accepted peer range, that your Nest major version is one of the two the module declares, and follow the Nest documentation recipe rather than the README, because the README itself points there for the actual setup steps.

Frequently asked questions

Official sources

1. License: MIT
2. nestjs/passport on GitHub
3. Project website
4. README
5. Releases