Implementation worksheet · 6 min read
An In-App Component Release Acceptance Checklist
Check twelve things before releasing a component that runs inside a customer's application: bundle size against budget, main-thread time against budget, no new global namespace or prototype modification, CSS scoped so it cannot leak either direction, no console output in production builds, graceful behaviour when the host page blocks network requests, correct teardown on unmount, behaviour when the host uses a conflicting framework version, no unhandled promise rejections escaping to the host's error tracking, accessibility of any focusable element, the two most recent host framework versions supported, and a smoke test against a real customer-shaped build rather than only against your demo page. The last one is the check that catches what the others miss.
Components that run inside other people's applications have an unusual failure mode: your bug becomes their incident, reported to their support team, attributed to their product. That asymmetry is why release acceptance for an embedded component needs to be stricter than for an application you own, and why the checks that matter are about not interfering rather than about working.
Put it into practice
1. Enforce size and main-thread budgets in the build
A number, failed automatically, not reviewed by eye. Budgets that are checked manually drift upward one acceptable increment at a time. The build failing is the only version that holds, and the number should be in the worksheet before the release rather than negotiated during it.
2. Confirm you have not touched anything global
No new globals, no prototype modification, no monkey-patching of fetch or history or console. Each of these works fine in isolation and breaks something unpredictable in a host application you cannot see. This is the category that generates the hardest support tickets, because the symptom appears far from the cause.
3. Check CSS isolation in both directions
Your styles must not leak into the host, and the host's must not break your component. Test against a page with aggressive global styles — a reset, a CSS framework, inherited font sizing. A component that only renders correctly on your demo page has not been tested.
4. Test with the network blocked
Ad blockers, corporate proxies and content-security policies all block third-party requests. Your component must degrade quietly rather than throwing, retrying in a loop, or rendering a broken shell. Failing silently is the correct behaviour here.
5. Verify nothing escapes into the host's error tracking
An unhandled rejection from your code appears in the customer's Sentry with their stack traces around it, and they will reasonably treat it as their bug. Catch at your boundary and report through your own channel.
6. Test against the two most recent host framework versions
And know which you support. A component that works on the current React and breaks on the previous one will encounter the previous one, because customers upgrade on their own schedule and not yours.
7. Smoke test on a customer-shaped build
Not the demo page. A real application with routing, existing global styles, other third-party scripts, and a slow network. Keep one such build as a test fixture — this single check finds more than the rest of the list combined, because the rest are testing conditions you already thought of.
8. Write down what changed and what it could affect
Consumers of a component cannot read your diff. A release note naming the behaviour that changed is what lets a customer decide whether to take it, and it is the difference between a version bump they trust and one they defer indefinitely.
Release acceptance checklist
Copy this structure into your review document and record your observed result for each row.
| Check | Budget or criterion | Automated | Passed |
|---|---|---|---|
| Bundle size (gzipped) | under budget | yes | |
| Main-thread time | under budget | yes | |
| No new globals | zero | yes | |
| No prototype or built-in patching | zero | yes | |
| CSS does not leak out | visual diff on a styled host | partly | |
| Host CSS does not break component | tested on aggressive reset | partly | |
| No console output in production | zero | yes | |
| Degrades when network blocked | quiet, no loop | yes | |
| Clean teardown on unmount | listeners and observers at baseline | yes | |
| No unhandled rejections escape | caught at boundary | yes | |
| Two most recent framework versions | both pass | yes | |
| Smoke test on customer-shaped build | manual | no | |
| Release note naming behaviour changes | written | no |
A failure worth checking
The demo-page pass. Every automated check is green and the component renders perfectly on the documentation site — a clean page with no global styles, no other scripts, a fast network and the exact framework version you develop against. It ships, and in a real application it inherits a font size from a global reset, competes with three other third-party scripts for the main thread, and throws on a framework version one minor behind. The customer-shaped build is on this list because a component tested only in its own environment has been tested in the one place it will never run.
Common questions
How strict should the size budget be?
Strict enough that exceeding it is a decision rather than an accident. The absolute number matters less than the fact that it fails the build — budgets reviewed by a human drift, and the drift is invisible because each increment is defensible on its own.
Should we support old framework versions?
Decide and publish the policy rather than discovering it per support ticket. Two recent major versions is a common commitment. What matters is that the answer exists before a customer asks, because the alternative is answering it differently each time.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.