---
title: v0.7.5 Release Notes
description: Draft release notes for v0.7.5 — install hygiene
---

# v0.7.5 — Install hygiene

> These notes are drafted here for the PR; the canonical source of truth is the
> [GitHub Release](https://github.com/open-agreements/open-agreements/releases)
> created when the `v0.7.5` tag is pushed. Copy this text into the release body.

## What changed

Moved `@google-cloud/firestore` and `@google-cloud/storage` out of the root package's runtime dependencies and into the internal `packages/signing/` workspace where the code that uses them actually lives.

These SDKs are only used by the hosted signing backend (the UseJunior-hosted Vercel API that handles DocuSign OAuth, envelope creation, and Firestore-backed token storage). CLI and MCP users were downloading ~180 transitive packages and ~50 MB of Google Cloud infrastructure they never executed, and every `npm install` triggered new `npm audit` findings that were scaring off cautious evaluators and failing strict CI pipelines.

No feature changes. No API changes. The hosted signing backend is unchanged — it now resolves its GCP SDK dependencies from the `packages/signing/` workspace instead of the root package, via standard npm workspace hoisting.

## Measured install impact

Fresh `npm install open-agreements` on `node:20-slim`:

| Metric | 0.7.4 | **0.7.5** | Delta |
|---|---|---|---|
| Wall clock | 14.5s | **3.6s** | **−75%** |
| Packages installed | 201 | **23** | **−178** |
| `node_modules` size | 74 MB | **23 MB** | **−69%** |
| `npm audit` findings | 7 (6 low, 1 high) | **0** | **−7** |

The high-severity `@xmldom/xmldom <0.8.12` finding that was present in 0.6.2 through 0.7.4 is also resolved in 0.7.5 because regenerating the lockfile picked up a newer `@usejunior/docx-core` that depends on `@xmldom/xmldom@0.9.9`. This was a bonus side effect of the dep relocation, not an intentional coordinated fix — but it means 0.7.5 ships with a clean audit.

## Why this happened

The 0.7.0–0.7.2 release cluster on Mar 31 added the new DocuSign signing integration. During that work, `@google-cloud/firestore` and `@google-cloud/storage` were added to the root `package.json` instead of to `packages/signing/package.json` where the importing code lives. Our existing [publishing guardrail in `openspec/project.md`](../../openspec/project.md) calls this out specifically: runtime dependencies must be declared by the package that imports them — no hoist-reliance, no phantom deps. We regressed against our own guidance.

Weekly npm downloads dropped from 2,818 (W13) to 1,954 (W14), with a sharp weekday cliff on Apr 2 (from ~300–500/day down to 95 on a normal Thursday). A Docker-instrumented install comparison traced the regression to the new dependency footprint: `npm audit` output began surfacing the literal string `open-agreements >=0.7.2 depends on vulnerable versions of @google-cloud/storage` on every install, and install time tripled.

## Guardrail

`scripts/check_isolated_package_runtime.mjs` now fails CI if `@google-cloud/firestore` or `@google-cloud/storage` appears in a fresh tarball install of `open-agreements`. Adding a new backend-only SDK to the root package by mistake will now trigger a loud failure before publish.

## Acknowledgements

Thanks to the community members who weren't able to `npm install` cleanly in the last two weeks. This should not have shipped, and the guardrail exists now specifically so it cannot recur.
