Baileys is a WhatsApp Web client on a release candidate tag, with its migration notes off-site

Version 7.0.0-rc14 sits beside a breaking change notice

`package.json` names the published version `7.0.0-rc14`, and the README opens with a CAUTION block announcing multiple breaking changes as of 7.0.0, with migration notes at https://whiskey.so/migrate-latest. The three most recent releases show the shape of that: `v7.0.0-rc13` on 2026-05-21, then `v6.7.24` and `v7.0.0-rc14` both on 2026-07-29, minutes apart.

The repository's 7.0.0-rc14 is a release candidate, while a 6.x line was also released that day. The installation guide distinguishes the stable npm release from the edge GitHub build; check the package registry's current distribution tags before choosing a version. A team pinned to 6.x and a team on 7.x are running different generations behind the same package name.

The README does not list the breaking changes itself; it points to the migrate-latest link, which lives on a separate site, so the authoritative upgrade information is the one artefact a pinned dependency cannot carry with it.

The preinstall script checks the Node.js version

The package's `preinstall` script runs `node ./engine-requirements.js`. The installation guide says this checks for Node.js 20.0.0 or newer and fails installation on an older version; confirm the requirements for the specific release you install.

`prepare` and `prepack` both run the build, and that build is not a bundler call:

"build": "tsc -P tsconfig.build.json && tsc-esm-fix --tsconfig=tsconfig.build.json --ext=.js"

Installing from a git URL or an archive therefore compiles TypeScript and runs a specifier fix-up pass locally. Next to that, `.yarnrc.yml` and `yarn.lock` are checked in even though every script is written as an `npm run` invocation: the project develops on Yarn, and the README documents Yarn commands, which is a combination to accept rather than one to untangle in your own repo.

type module, one entry point, and no CommonJS build

`"type": "module"` puts the whole package in ESM territory. `main` is `lib/index.js`, `types` is `lib/index.d.ts`, and `package.json` shows `main` and `types` entries. A project still calling `require()` may need its own interop layer. The `tsc-esm-fix` step in the build exists because the emitted JavaScript needed its specifiers rewritten, so the package shape is an ESM package on purpose rather than by accident of tooling.

Type declarations are published, not generated on demand, so what your editor shows comes from the `lib/index.d.ts` tree belonging to the version you installed. That matters most across a major version, when the declarations and the guide are updated at different moments.

There is a local fallback for documentation gaps. `build:docs` runs `typedoc` against a checked-in `typedoc.json`, and a `docs/` directory sits at the repository root, so the API surface can be regenerated from source instead of fetched from a website that may have moved on.

The new guide is unfinished, the old one still lives in README.md

The README calls itself a temporary README.md, says the new guide at https://baileys.wiki is in development, and says this file will be replaced by .github/README.md. The older guide is still present in README.md, so two guides of different vintages are live at once.

The cost lands hardest during a major-version transition, because there are then three sources: the breaking change list for 7.0.0 at https://whiskey.so/migrate-latest, the current usage guide on the wiki, and the detailed prose for earlier versions in the README file you are simultaneously being told is superseded. A reader arriving from a search result can land on any one of the three and act on it.

If a wiki page is absent, regenerate the typedoc output with `npm run build:docs` and read that instead of waiting on the site.

test:e2e switches off certificate verification for the whole run

The end-to-end suite is one line worth reading before it goes anywhere near CI:

"test:e2e": "NODE_TLS_REJECT_UNAUTHORIZED=0 node --experimental-vm-modules ./node_modules/.bin/jest --runInBand --forceExit --testMatch '**/*.test-e2e.ts'"

`NODE_TLS_REJECT_UNAUTHORIZED=0` makes Node accept any certificate from any host for the duration of the run, so a suite executed this way cannot detect interception and a green result says nothing about the transport it used. The same line runs with `--runInBand`, so cases execute serially, and `--forceExit`, which ends the process once Jest finishes instead of waiting on open handles to drain.

The unit suite beside it, `test`, uses the same Jest runner under `--experimental-vm-modules` but leaves certificate checking alone. Keep the two separated in your own pipelines: a failure in the e2e job tells you something about protocol behaviour, never about who was in the middle of the connection.

The disclaimer puts the Terms of Service exposure on whoever runs it

The README states that the project is not affiliated with, associated with, authorized by or endorsed by WhatsApp, and that the maintainers do not condone use which violates WhatsApp's Terms of Service. It goes further in plain words: use at your own discretion, do not spam people with this, and it discourages stalkerware, bulk or automated messaging usage.

For a reader the consequence is that the Terms of Service question has one answer and the MIT grant does not settle it. An MIT licence obliges you to keep the copyright notice; it obliges WhatsApp to nothing and says nothing about the service terms you reach the server under.

Commercial support is routed to the current maintainer through purpshell.dev, with sponsorship on the same site, and the README is explicit that paying for support is not an endorsement of using the library. A business reading this section should treat it as the library's own statement of where it stands.

WAProto ships in files, and regenerating it needs a POSIX shell

The `files` array is `lib/**/*`, `WAProto/**/*` and `engine-requirements.js`, so the generated protocol definitions travel with the compiled library and can be imported from an installed copy rather than only from a git checkout. Regenerating them is a separate step with a shell baked into the command:

"gen:protobuf": "sh WAProto/GenerateStatics.sh"

`sh` is the program being run, so on a machine with no POSIX shell on PATH that line stops immediately rather than falling back to something else. Alongside it the repository carries `proto-extract/`, `scripts/`, `AGENTS.md`, `CLAUDE.md`, `SECURITY.md` and `typedoc.json`, which says the protocol layer is produced rather than hand-maintained and that contributor instructions live in the tree.

For most consumers none of this matters, because you import the published definitions. It matters the day you need to read what a changed message type actually decodes to, since that path runs through a shell script and a checked-in generated tree instead of your own tooling.

Against WhatsApp itself, the difference is who signs the contract

The alternative is not another library. It is WhatsApp, whose official site the README names at whatsapp.com while disclaiming any connection to it, and that disclaimer is the clearest statement of the difference in approach available.

Baileys is a WebSockets client for the WhatsApp Web API, holding its session inside your own process with protocol definitions you can read in `WAProto/`, and it carries no agreement with WhatsApp of any kind. Whatever WhatsApp offers directly comes from WhatsApp, under the terms WhatsApp publishes, and the README places all of that outside the library. So this is not a comparison between two packages. It is a choice between a programmable session against the web client, under a licence that commits nobody, and an official channel where the counterparty is WhatsApp itself.

A team that has to answer to WhatsApp's review process has no real choice here. A team that needs to drive an existing web session from code it can read has little reason to look elsewhere.

Editorial conclusion

Baileys fits a team that wants to drive a WhatsApp Web session from TypeScript it can read, and it fits a product badly if that product needs a sanctioned channel, because the README states plainly that nothing here is affiliated with WhatsApp and that the maintainers discourage stalkerware, bulk or automated messaging. The library is MIT licensed, the repository is not archived, and the last push was on 2026-11-01. Pin your major version deliberately: the published tag is 7.0.0-rc14, the README carries a breaking change notice for 7.0.0, and the migration notes live at https://whiskey.so/migrate-latest rather than in the repository.

Frequently asked questions

Official sources

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