chore: tag e2b.dev links with UTM parameters - #330
Conversation
READMEs follow the org's existing utm_campaign=readme convention; package homepage fields use utm_source=pypi/npm so installs from registry pages attribute to their real source (takes effect on next publish). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a0ae39ea26
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
There was a problem hiding this comment.
LGTM — this is a low-risk documentation/config change (UTM parameters on e2b.dev links and package homepage fields), no functional code paths affected.
Extended reasoning...
Overview
This PR touches three files: the root README.md, js/package.json, and python/pyproject.toml. It appends UTM query parameters (utm_source, utm_medium, utm_campaign, utm_content) to existing e2b.dev links for marketing attribution purposes. No code logic, build config, or dependency versions are changed.
Security risks
None. UTM parameters are purely additive query string tracking params on outbound links to the project's own domain (e2b.dev). There is no injection, auth, or data-exposure surface here — these are static string edits to documentation and metadata fields.
Level of scrutiny
This warrants light scrutiny. It's a marketing/attribution chore with zero impact on runtime behavior, SDK functionality, or the build/publish pipeline (the homepage field is metadata only). The one finding from the bug hunt — that js/README.md and python/README.md (the READMEs actually rendered on the npm/PyPI package pages) were left untagged despite being the exact channels this PR's homepage changes target — is a completeness nit, not a correctness bug, and is already captured as an inline comment.
Other factors
No prior reviews exist on this PR. The change is self-contained, mechanical, and the linked URLs/parameters are correctly formed (valid query string syntax, no broken links). The nit doesn't block merge — the PR's core goal (tagging homepage/README links) is achieved for the files it touched.
Review follow-up: js/README.md and python/README.md are what the registries render, so their links carry utm_source=npm/pypi to match the homepage fields. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Good catch — those two files are indeed what npm and PyPI render. Tagged all four e2b.dev links in each, with utm_source=npm / utm_source=pypi to match the per-registry granularity of the homepage fields. |
|
add changeset also pls |
Will do! |
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Changeset added — patch bump for @e2b/code-interpreter, which also gets the tagged homepage field onto the npm page with the release. |
The PR changes python/README.md and python/pyproject.toml, but the changeset only named @e2b/code-interpreter. is_release_for_package.sh gates the PyPI publish on a changeset naming @e2b/code-interpreter-python, so the Python homepage change would not have shipped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
READMEs follow the org's existing utm_campaign=readme convention. The package homepage fields get utm_source=pypi/npm so installs coming from registry pages attribute to their real source — that part takes effect on the next publish.
🤖 Generated with Claude Code