ABAP ADT 接口契约

mcp-abap-adt-interfaces

Contracts for the MCP ABAP ADT packages: types and constants, no implementations.

TL;DR

• Install the package whose contracts you accept, not all of them.
• @mcp-abap-adt/interfaces is gone. It was a deprecated facade that forwarded the others, and forwarding is what bound a consumer to the release rate of contracts it does not use. npm still serves 51.0.0 for anyone pinned to it; nothing further is published.
• No package here depends on an implementation or a runtime package.

Why these packages

One version line for every contract meant an ADT major bumped a package that only needed IAuthProvider. Decision 26 in docs/architecture/DECISIONS.md says whether a contract belongs in this repository at all; decision 35 says which package holds it — the one whose subject the contract's own fields name, not the one its first acceptor happens to be, because auth-providers accepts both ITokenProvider and ISapConfig and the accepting side therefore answers nothing. Decision 38 adds the case the subject does not settle: the ABAP connection is ADT, and has its own package because it releases on its own schedule — a connector should not follow every major of the object contracts. Decision 41 applies 35 to a package that held two subjects: the destination and its stores — the broker's port — left interfaces-auth-sap for interfaces-auth-broker, so a provider or a connection no longer follows the broker's releases. The design is in docs/architecture/ARCHITECTURE.md.

Working in this repository

npm ci                    # the root's tools
npm run install:packages  # each package's own dependencies, from the registry
npm run check             # build, type checks, placement, graph, packed tarballs, release tool

The packages are not workspaces. Each one installs its dependencies — its siblings included — from the npm registry and builds against them; nothing links one package to another's source. What passes here is what a consumer installs. The order they build and publish in is publishOrder in the root package.json, dependencies first. A change one package needs from another is published first; the dependent then raises its range.

npm run check is what holds, and every package's prepublishOnly runs it. CI (.github/workflows/ci.yml, Node 22, 24 and 26) runs the same checks and npm run lint:check on every pull request and on every push to master.

The compiler is strict beyond strict. tsconfig.base.json, which every package extends, adds noImplicitReturns, noFallthroughCasesInSwitch, noImplicitOverride, noUncheckedIndexedAccess and exactOptionalPropertyTypes. npm run test:check type-checks everything under each package's src, its __typechecks__ included; the build leaves those out. npm run lint:check fails on a warning, and noExplicitAny is an error, with no exception.

Publish with npm run release:publish. It publishes only the packages whose version is not on the registry yet, in dependency order (interfaces-utils, interfaces-network, interfaces-auth, interfaces-auth-sap, interfaces-auth-broker, interfaces-calm, interfaces-adt-connection, interfaces-adt), and runs npm run check once rather than once per package. Everything goes out first; afterwards it asks the registry which versions are being served and names any that are not yet, or that it could not check. A version npm refuses and the registry then vouches for was published by an earlier run, and the summary says so rather than counting it as this one's. That is exit 2 — published, not confirmed — and is not a failure; wait for npm view <package> versions --prefer-online to show the version before re-running, because a re-run before then puts the package back in the plan. Exit 1 is a publish that errored with no version on the registry to account for it, and stops the run there; a publish npm refuses for a version the registry does serve is treated as already published, which is what a re-run meets when the read that built the plan was stale. npm run release:publish -- --dry-run prints the plan and changes nothing.

It refuses to publish unless the tree is the tagged release: a dirty tree, a version with no matching tag, a tag that is not an ancestor of HEAD, or any difference between HEAD and that tag. Ancestry alone would let a commit made after the tag change a package without bumping it, and the tarball would then carry content the tagged version never had — so release, tag and publish from one commit; if HEAD has moved on, git checkout <tag> and publish from there.

A prerelease version requires a dist-tag other than latest (npm run release:publish -- --tag=next); on latest it would reach everyone who asked for the stable line. Publishing to latest is also refused when it would move that tag backwards, compared with real SemVer precedence rather than string order. Both rules key on whether the publish targets latest, not on whether a --tag was given, so --tag=latest is treated exactly like passing none.

Do not publish the packages by hand. npm publish for every package republishes the ones that have not changed, and npm answers each with You cannot publish over the previously published versions — errors that are expected, and therefore skipped over, and therefore hide the one that is not.

Licence

GNU Lesser General Public License v3.0 only (LGPL-3.0-only) for every package. See LICENSE and COPYING.