Product Decisions This Supports
- Whether to commit to WeChat Work (企业微信) as a channel. This package is the contract layer only — interfaces, DTOs, enums, exceptions — for the Tourze WeChat Work family. It tells you what a WeChat Work integration looks like in PHP, not whether one works. Treat it as a scoping artifact, not a capability.
- Build vs. buy at the seam, not at the feature. The decision this actually unlocks is: do we standardize our internal WeChat Work adapter against Tourze's contracts, or against EasyWeChat / Tencent's official SDK? Choosing this package means buying into a specific object model, and paying a migration cost if you later change your mind.
- Version-pinning and upgrade policy. The 0.0.5 → 1.0.2 jump is the headline. For a contracts package, 1.0 is a semver promise that interface signatures are frozen. That converts a "watch it" dependency into something you can pin as
^1.0 and take patches on with low churn risk — if the jump was clean.
- Test strategy. A contracts-only dependency is cheap to fake. If you adopt it, you get typed test doubles for message payloads, org/user records, and approval objects without standing up a real WeChat Work tenant.
- Not supported by this release: any decision about sending messages, syncing org structure, or passing WeChat Work compliance review. None of that runtime lives here.
When to Consider This Package
Adopt when:
- You are already inside the Tourze ecosystem, or a vendor/contractor has handed you a codebase built on it — adopting the contracts keeps you compatible rather than fighting the object model.
- You need a stable interface to code your own adapter against, and you want the concrete implementation (likely a sibling
tourze/wechat-work package) to be swappable.
- You want typed PHP representations of WeChat Work payloads and are willing to accept a thin, small-maintainer library to get them.
- Your integration surface is small and internal — approvals, notifications, lightweight org sync — where an adapter boundary is your real insurance policy.
Look elsewhere when:
- You need working WeChat Work functionality today. This package alone ships zero runtime. Evaluate the sibling implementation package, or compare against EasyWeChat's WeChat Work module and Tencent's official SDK — both have materially deeper documentation, community, and issue history.
- You need vendor support, SLAs, or Chinese-market compliance guidance. A single-maintainer OSS contracts package is not that.
- The WeChat Work requirement is one message type or one webhook. A full contracts dependency is overkill; a
Http::post() and a DTO you own is smaller and clearer.
- You are risk-averse on supply chain. Uninformative release notes and a 0.x → 1.x jump with no migration guide is a hygiene signal, not a dealbreaker — but it should raise the bar for how tightly you couple.
Immediate diligence before adopting 1.0.2: the release note is a bare diff link, and the jump skips 0.0.5 → 1.0.2 without accounting for 1.0.0 and 1.0.1. Read the git diff and the CHANGELOG directly. A major-version bump on a contracts package is precisely the class of change that breaks every downstream implementer. Do not bump the constraint on faith.
How to Pitch It (Stakeholders)
To executives: "We are evaluating a small open-source component that defines the data shapes for connecting to WeChat Work, a Chinese enterprise messaging platform. It's plumbing, not a product — it enables a channel, it doesn't build one. Cost to evaluate is a few engineering days and the risk is fully contained because we would keep it behind our own interface, so it can be removed without touching product code. The news is that it just reached a stable 1.0, which makes it a safer thing to depend on than it was a week ago."
To engineering: "Contracts-only package — interfaces and DTOs, no HTTP client, no runtime. Version 1.0.2 means semver is now in play, so pin ^1.0 and stop thinking about it. Two caveats before you do: the release notes are a single diff link with no migration guidance, and the version went from 0.0.5 straight to 1.0.2 — so read the diff for breaking interface changes and check whether the 1.0.0 release is documented anywhere. Assume the 1.0 was cut without a written upgrade path and verify rather than trust. Keep it behind an adapter boundary we own; if the project stalls or the contracts churn, we swap the implementation and keep our call sites."
The one-line version: worth a spike, not worth a commitment — stabilize it behind our own abstraction, and re-evaluate only if we ship a real WeChat Work integration.