Skip to content

[codex] add Google Analytics tag - #3

Merged
jdx merged 1 commit into
mainfrom
codex/add-google-analytics-tag
Apr 18, 2026
Merged

jdx merged 1 commit into
mainfrom
codex/add-google-analytics-tag

Conversation

@jdx

@jdx jdx commented Apr 18, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

  • Adds the Google tag manager script to the shared VitePress head configuration.
  • Configures measurement ID G-WD1RRC0F8C so the docs site includes analytics on every page.

Validation

  • npm run docs:build

Note: the docs worktree did not have node_modules, so I installed the declared docs dependency with npm install --no-save --no-package-lock to run the build, then removed generated docs/node_modules and docs/.vitepress/dist before committing.


Note

Low Risk
Low risk: docs-only change that injects third-party analytics scripts; main risk is privacy/compliance and any unintended script loading impact on the docs site.

Overview
Adds Google Analytics tracking to the docs site by injecting the gtag.js loader and inline gtag('config', 'G-WD1RRC0F8C') initialization into the shared VitePress head config, enabling page-wide analytics on every docs page.

Reviewed by Cursor Bugbot for commit 3584219. Bugbot is set up for automated code reviews on this repo. Configure here.

@jdx
jdx marked this pull request as ready for review April 18, 2026 18:40
@greptile-apps

greptile-apps Bot commented Apr 18, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR adds Google Analytics 4 (GA4) tracking to the aube docs site by inserting the standard gtag.js snippet into VitePress's shared head configuration with measurement ID G-WD1RRC0F8C. The two-part snippet — an async external script loader and an inline initialization block — follows the canonical GA4 pattern and integrates cleanly into the existing docs/.vitepress/config.mts.

  • The VitePress head tuple format ([tag, attrs, content]) is used correctly for both the external and inline scripts.
  • The async: \"\" attribute on the loader script follows the correct VitePress convention for boolean HTML attributes.
  • The measurement ID is consistent between the loader URL and the gtag('config', ...) call.
  • No functional regressions to existing config sections (favicon, manifest, theme-color, nav, sidebar) are introduced.

Confidence Score: 5/5

Safe to merge — change is a well-formed, standard GA4 integration with no functional risk to the docs build.

The snippet exactly matches the canonical GA4 pattern, measurement IDs are consistent across both script elements, the VitePress head tuple format is used correctly, and the change is scoped to a single config file with no logic impact.

No files require special attention.

Important Files Changed

Filename Overview
docs/.vitepress/config.mts Adds standard GA4 gtag.js snippet (external loader + inline init) to the VitePress head array; implementation is correct and consistent.

Sequence Diagram

sequenceDiagram
    participant Browser
    participant GTM as gtag.js CDN
    participant GA as Google Analytics

    Browser->>GTM: GET googletagmanager.com/gtag/js?id=G-WD1RRC0F8C (async)
    GTM-->>Browser: gtag library
    Browser->>Browser: execute inline init script
    Browser->>GA: gtag('config', 'G-WD1RRC0F8C') → page_view event
    GA-->>Browser: 200 OK (beacon)
Loading

Reviews (1): Last reviewed commit: "add google analytics tag" | Re-trigger Greptile

@jdx
jdx merged commit 7ed3287 into main Apr 18, 2026
11 checks passed
@jdx
jdx deleted the codex/add-google-analytics-tag branch April 18, 2026 18:44
jdx added a commit that referenced this pull request Apr 22, 2026
## Summary

- `ensure_installed` walked up to the nearest `package.json`, which in a
monorepo subpackage stops at the subpackage. The install state file only
exists at the workspace root, so every `aube run` / `exec` / `start`
from a subpackage reported `install state not found` and spuriously
re-ran install even when the root tree was fresh.
- Prefer `find_workspace_root` as the freshness anchor, fall back to
`find_project_root` for non-workspace projects, and finally to the cwd.
- Added a regression test: `aube install` at the workspace root, then
`aube start` from `packages/app` must not print `Auto-installing`.

## Why

User report (bug #3): `aube start` in a workspace package re-ran install
on every invocation after a root `aube install`. The freshness check was
reading the wrong `node_modules/.aube-state` path.

## Test plan

- [x] `cargo clippy --all-targets -- -D warnings`
- [x] `cargo test --release -p aube` — 278 unit + 4 e2e pass
- [x] `mise run test:bats test/run.bats` — 17 tests pass, including the
new regression

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Changes the directory used to determine dependency freshness for
auto-install, which can affect when installs run in monorepos vs
single-package projects. Risk is limited by simple fallback logic and
added end-to-end regression coverage.
> 
> **Overview**
> Fixes auto-install staleness checks in workspaces by anchoring
`ensure_installed` at the *workspace root* (falling back to the nearest
`package.json`, then the current directory) so subpackages reuse the
root `.aube-state` instead of repeatedly reporting missing state and
re-installing.
> 
> Adds a Bats regression test that runs `aube install` at the workspace
root and then `aube start` from `packages/app`, asserting it does
**not** print `Auto-installing`.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
edf9b04. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jdx added a commit that referenced this pull request May 3, 2026
* Skip empty bytes_segment so the phase-2 label doesn't render a
  doubled `·  ·` separator on installs without `dist.unpackedSize`
  (Greptile P1).
* Switch ETA to fetch-window throughput: snapshot completed at the
  set_phase("fetching") boundary, then divide remaining work by
  `fetch_elapsed_ms / (completed - baseline)`. Falls back to `ETA …`
  while the baseline or fetch window are missing. Eliminates the
  pessimistic "110s ETA after a 3s resolve" case (Greptile P2).
* Reconcile estimated_bytes after filter_graph: track per-dep_path
  unpacked_size during streaming, then re-sum surviving dep_paths
  via the new InstallProgress::reconcile_estimated_bytes API.
  Mirrors the package-denominator reconcile applied next to it
  (Greptile P3).
* Apply TARBALL_COMPRESSION_RATIO in TTY refresh_bytes_segment too —
  CI mode applied it; TTY was showing the raw unpacked sum (~3.3×
  inflated) (Cursor #1).
* Refresh ETA on every inc_downloaded_bytes so it doesn't freeze
  during long downloads when no inc_total / inc_reused events fire.
  Documents the trade-off at FetchRow::drop where a refresh would
  require a larger refactor (Cursor #3).
* Style only the ✓ green on the install / no-op summaries instead
  of the whole sentence; aligns with the CI heartbeat summary's
  styling so the success cue stays sharp without bleeding green
  across the line (Cursor #4 + user request).
* Standardize the ✓ prefix on both Already-up-to-date paths
  (`print_install_summary` and `print_already_up_to_date`).

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jdx added a commit that referenced this pull request Oct 20, 2026
aube-written `pnpm-lock.yaml` files leave out optional peers that pnpm
11 resolves, so Dependabot (which runs pnpm) rewrites snapshot keys it
did not need to touch. This is difference #2 of discussion
#1779. Difference #1 (suffix
order) is in #1792 and #3 (unused
catalog entries) in #1788.

I ran `pnpm@11.27.1 install --lockfile-only` on small fixtures to
establish the rules, and the aube output now matches pnpm's `snapshots:`
byte for byte on all of them (and on the importer rows):

1. **Optional peers resolve from anywhere in the graph (when
`dedupePeerDependents` is on, the default).** If a satisfying version is
already resolved anywhere in the workspace, even in an unrelated
importer's subtree, pnpm binds it. With `autoInstallPeers: false`,
`vite@7.1.0` in one importer gets `(jiti@2.7.0)` when only another
importer's `c12` pulls in jiti. aube only looked at ancestors, the
package's own deps and the workspace root. This also covers debug's
`supports-color`, which pnpm 11 binds when `chalk` brings it in.
2. **A resolved optional peer is listed under `optionalDependencies:`**
in the snapshot, not `dependencies:`.
3. **Compatible variants of the same package merge across importers.**
Importer `a` resolving vite with `jiti` and importer `b` with `yaml`
both end up as `vite@7.1.0(jiti@2.5.1)(yaml@2.8.1)`. Variants whose
peers conflict (different `jiti` versions) stay separate.

Before (importer `apps/web` and `apps/other` share vite, only `web` has
jiti and yaml):

```
apps/other: vite 7.1.0(@types/node@24.3.0)(tsx@4.20.5)
apps/web:   vite 7.1.0(@types/node@24.3.0)(jiti@2.5.1)(tsx@4.20.5)(yaml@2.8.1)
```

After (same as pnpm 11):

```
apps/other: vite 7.1.0(@types/node@24.3.0)(jiti@2.5.1)(tsx@4.20.5)(yaml@2.8.1)
apps/web:   vite 7.1.0(@types/node@24.3.0)(jiti@2.5.1)(tsx@4.20.5)(yaml@2.8.1)
```

With `dedupePeerDependents: false` pnpm 11 leaves those peers
unresolved, and so does aube.

## Migration

Existing aube-written lockfiles shift once on the next resolve for any
package whose optional peers are now resolved. Lockfiles are read as-is,
so frozen installs of old lockfiles keep working.

## Not covered yet

Running both tools fresh on the repro repo (speakeasy-api/gram at
e537882348) still leaves differences. They come from optional peers a
package gets only because a *descendant* needs them, e.g.
`@ai-sdk/react@4.0.138(react@19.3.0)(zod@4.6.7)`, where `zod` is only a
peer of its child `@ai-sdk/mcp`, and
`@testing-library/react@14.0.0(@types/react@…)`. pnpm hoists those
resolved optional peers into the importer's scope so every package below
sees them; aube's ancestor-propagation gate does not. I did not change
that because I could not pin the rule down from output alone without
risking regressions. This is a follow-up.

## Validation

- Compared `snapshots:` against `pnpm@11.27.1` on fixtures covering:
optional peer provided by another importer's subtree, by the root, by a
cousin dep, version conflicts across importers, three importers with
partial overlap, dedupePeerDependents off, and required peers across
importers (already matching).
- The old unit test `optional_peer_is_not_bound_via_graph_scan` asserted
the opposite of pnpm 11's behavior (which I checked: pnpm 11.27.1 binds
`supports-color@7.2.0` for `debug` when `chalk@4` is in the graph). It
is replaced by tests for the new behavior, plus a variant-merge test.
- `cargo test`, `cargo clippy --all-targets -- -D warnings`, `cargo
fmt`; bats `peer_deps`, `peers`, `install`, `update`, `prune`,
`optional_platform`, `pnpm_monorepo_dedupePeers`.

*AI-assisted — Tool: Claude Code; model: anthropic/claude-sonnet-5-5;
version: unavailable.*

🤖 Generated with [Claude Code](https://claude.com/claude-code)


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Improved optional peer dependency resolution across the dependency
graph when deduplication is enabled.
* Compatible optional peers are now consolidated across variants, while
conflicting versions remain separate.
* Resolved optional peers are recorded correctly, and unresolved peers
continue to be reported when no satisfying version is available.
  * Clarified peer dependency resolution behavior in relevant output.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant