Seneca's manifest says 4.0.0-rc5 while its newest tag is v3.22.0 from 2020

The manifest reads 4.0.0-rc5 and the newest tag is from 2020

The root `package.json` declares version `4.0.0-rc5`, a release candidate on the 4.0 line, and the most recent commit is dated 17 August 2026. The tags tell a different story: v3.22.0 from 26 September 2020, v3.7.0 from July 2018 and v3.6.0 from May 2018. So the working tree has moved well past the last tag while the tagged history stopped more than five years ago.

Nothing in the repository reconciles the two numbers. There is no changelog entry in the README tying 4.0.0-rc5 to v3.22.0, and the only other record of changes is `CHANGES.md` at the root. For anyone deciding what to install, the distinction matters: pinning to a tag gets the 3.x line, while the default branch carries an unreleased 4.0 candidate whose compatibility with 3.x plugins is not stated in the files at the root.

The maturity claim cites eight years in production and a lightning strike

The feature list makes five claims and the third is the memorable one: maturity, described as eight years in production before the authors called it microservices, with the aside that the project was once taken out by lightning. The other four are pattern matching, transport independence, a deep and wide plugin ecosystem, and a book on designing microservice architectures.

The funding and responsibility lines are equally direct. The module is sponsored and supported by Voxgig, Richard Rodger is listed as lead maintainer, and the manifest repeats him as author with a long contributor list behind it. Against 3956 stars the repository carries 214 open issues, so the plugin ecosystem the README points at is where most of the practical knowledge lives rather than in the core documentation.

A command is any property you choose to match on

The sales tax example is the whole model in a dozen lines. A pattern is registered with `seneca.add`, an action is fired with `seneca.act`, and the two are linked by nothing more than a property in the JSON:

var seneca = require('seneca')()

seneca.add({cmd: 'salestax'}, function (msg, done) {
  var rate  = 0.23
  var total = msg.net * (1 + rate)
  done(null, {total: total})
})

seneca.act({cmd: 'salestax', net: 100}, function (err, result) {
  console.log(result.total)
})

The README then makes the point that surprises newcomers: there is nothing special about the property `cmd`. It is simply the property being matched, and a framework that cared about nothing else would match on `foo` instead. Both the pattern and the payload can also be written as a string, `seneca.act('cmd:salestax,net:100', ...)`, or split across two arguments, `seneca.act('cmd:salestax', {net: 100}, ...)`, which is described as a convenient way of combining a pattern with parameter data.

listen() turns the process into an endpoint without changing the code behind it

Transport independence is demonstrated by moving one command out of the process. A `config` command that returns a rate is registered exactly as before, and then `seneca.listen()` starts a web server that accepts JSON messages, submits them to the local instance and returns the result as the HTTP response. The README notes that Seneca can also listen over a message bus instead.

The client side mirrors it. `seneca.client()` marks the process as a caller, and the `salestax` handler still asks for configuration with `seneca.act`, so the implementation of the configuration code stays the same whether it answers from memory or across a network. Nothing in the handler knows where the reply came from, which is the property the framework is selling.

One flag decides whether your logs are JSON or a debug transcript

The running section covers two invocations and one difference. Normally you start the script with `node microservice.js`, and logs come out as JSON so they can be shipped to a logging service. In test mode you add `--seneca.test`, and the output becomes human-readable with full debug logs.

$ node microservice.js --seneca.test

That flag is the whole operational surface for a Seneca process in the README: no port configuration, no host setting, no environment variable list. Anything else a deployment needs, such as which transport to bind or how to authenticate inbound messages, is not covered there, so it is either in the plugin of your choice or in your own code.

The compiled JavaScript, the source map and the coverage report are committed

The root holds `seneca.ts` as the TypeScript source next to the built `seneca.js` and `seneca.js.map`, with a hand-visible `seneca.d.ts` for types and a `lib/` directory alongside. A `coverage/` directory sits at the root too, and `.coveralls.yml` shows where coverage results are meant to go, while `.eslintrc.js` and `.prettierrc` handle style.

Two more directories have no obvious role from the outside. `docs/` is generated, not written: running `npm run annotate` produces an annotated version of each source file there. `trial/` has no description anywhere in the README. So the repository ships build output and coverage data as tracked files, which makes the diff of any commit larger than the code change would suggest.

The quick example stops on a half-typed comment

The Quick Example section defines three functions, `rejector`, `approver` and `local`, each adding a handler for `cmd:run` and returning a tag, with `local` calling `this.prior` to defer to whatever handled it before. The section then ends on an unfinished comment line, `// Services can listen for messages usin`, with the rest of that sentence and the rest of the example absent.

The README carries on regardless, moving into the running instructions, the motivation section and the programmer anarchy argument for lots of small processes, so the gap is one block rather than the rest of the document. The three handlers do show the mechanism the rest of the toolkit depends on: several functions claim the same pattern, and `this.prior` is how a later one reaches the earlier.

Editorial conclusion

Seneca fits a Node.js codebase that wants its business logic expressed as named commands rather than as objects passed between services, and it fits a team willing to treat message patterns as its public interface. Before depending on it, check which line you are actually installing: the manifest reads 4.0.0-rc5, a release candidate, while the newest published tag is v3.22.0 from September 2020 and the most recent commit is dated 17 August 2026, so the branch and the tagged releases are far apart. Read the two run modes too, because the difference between JSON logs and the full debug output of the test flag changes what your log pipeline can accept. And expect a learning curve in the naming, since the whole design assumes that whoever reads a pattern six months later can tell what the command does.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes