A personal community project under @kyletaylored, MIT licensed.Not provided or supported by Datadog.

Contributing an adapter

An adapter is a small module: subscribe to the platform's own events, map them onto the shared schema, call the RUM API. Everything else — dedupe, the consent gate, the PII filter, size caps, the debug log — lives in the core, so you do not write any of it. The target is a week from first commit to merged PR.

Scaffold

git clone https://github.com/kyletaylored/datadog-rum-community-plugins
cd datadog-rum-community-plugins
npm install
npm run new-plugin -- bigcommerce --title "BigCommerce" --family commerce --github your-handle

That copies templates/plugin into packages/plugin-bigcommerce and renames everything. Its tests pass against an empty mapping on purpose, so you start from green and watch each assertion tighten as you fill it in.

What you write

1. Record real fixtures. Capture actual payloads from the platform intofixtures/*.json, trimmed to the fields you read. Say in the file where they came from. Include at least one payload carrying something that must be stripped — a card field, an email — so the privacy rules are exercised rather than assumed.
2. Map them. In src/index.ts, subscribe to the platform's events and calltracker.track(...). Send numbers as numbers. Pass email and name straight through and let the core decide whether they are sent — do not gate them yourself.
3. Declare the footprint. Every global you read, event you subscribe to, storage key you write and RUM API you call, in both FOOTPRINT and plugin.json. The conformance suite fails if the run touches something undeclared.
4. Point the harness at your platform. Fill in the test's emit so fixtures reach the adapter through its own subscription, rather than calling the mapper directly. Testing the mapper alone would miss the part most likely to be wrong.
5. Run it. npm run verify builds, tests, validates the manifest and checks the size budget.

What the harness gives you

• A fake publicApi that records instead of sending, so no test needs a real RUM init.
• A fixture runner that replays recorded payloads through your adapter's own subscription.
• The conformance suite, which every adapter runs with no extra code.
• A snapshot of every mapped action, which also generates your plugin page's "Events this plugin sends".

Rules that will fail your PR

• An action name that is not in the schema, or a commerce prefix applied to another family.
• An attribute the schema does not define, or one sent with the wrong type — a numeric string instead of a number, for instance.
• Any blocked key reaching addAction or setUser: card fields, email, phone, address, search text.
• items[] sent without includeItems, over 20 entries, or carrying non-GA4 item fields.
• More than one commerce.purchase per transaction_id, or one with no transaction_id at all.
• Anything sent before consent, when a consent source is declared.
• A CDN bundle over 5 KB gzip.
• A footprint that does not match what the fixture run did.

Hard rules

• Never call datadogRum.init. The customer's init owns the application ID, sampling and privacy settings. @datadog/browser-rum is a peer dependency, never bundled.
• Public API only. Call only the publicApi methods. The core is the single place that depends on the SDK's internal plugin type, so an upstream change is one edit, not one per adapter.
• Platform code stays in the adapter. If you find yourself writing dedupe or a consent gate, it belongs in the core instead — open an issue.
• Compose, don't replace. Where Datadog ships an official plugin for a platform, add to it rather than reimplementing it.

Tiers and review

Each adapter gets a CODEOWNERS entry. An adapter with no maintainer activity for six months is marked deprecated in the gallery rather than silently rotting.

Releasing

Add a changeset with your PR (npm run changeset). Merging to main opens a release PR that bumps only the changed packages; merging that publishes them with provenance and computes the SRI hash for each CDN build.