chore(deps): unpin @types/google.maps (3.65.x DrawingManager typings) (deferred from #230) #236

Open
opened 2026-06-17 04:57:46 +00:00 by spikerj · 3 comments
Owner

Split out from #230 (frontend app-runtime libraries roll-up). @types/google.maps was excluded from the bump and pinned to 3.64.1 (exact, no caret) because 3.65.x breaks our build.

Problem

@types/google.maps@3.65.1 removes setMap and setDrawingMode from the google.maps.drawing.DrawingManager type. The production build fails in projects/spikersoft/src/app/_services/marks-site/marks-map/marks-drawing.service.ts:

TS2339: Property 'setDrawingMode' does not exist on type 'DrawingManager'.
TS2339: Property 'setMap' does not exist on type 'DrawingManager'.

Note: @angular/google-maps also depends transitively on @types/google.maps, so the caret range floated the shared copy up to 3.65.1; the exact pin keeps both deduped at 3.64.1.

Work required

  • Investigate the 3.65.x DrawingManager typing change (regression vs. intentional API surface change).
  • Update marks-drawing.service.ts to the supported pattern (e.g. setOptions({ map }) / setOptions({ drawingMode })) if those methods were intentionally dropped, OR confirm a later 3.65.x patch restores them.
  • Remove the exact pin, restore ^3.65.x, regenerate the lockfile.
  • Verify: nx build spikersoft --configuration=production succeeds.

Context

Pinned exact in #230's PR to prevent the lockfile from floating back to the broken typings.

Split out from #230 (frontend app-runtime libraries roll-up). `@types/google.maps` was excluded from the bump and **pinned to `3.64.1`** (exact, no caret) because 3.65.x breaks our build. ## Problem `@types/google.maps@3.65.1` removes `setMap` and `setDrawingMode` from the `google.maps.drawing.DrawingManager` type. The production build fails in `projects/spikersoft/src/app/_services/marks-site/marks-map/marks-drawing.service.ts`: ``` TS2339: Property 'setDrawingMode' does not exist on type 'DrawingManager'. TS2339: Property 'setMap' does not exist on type 'DrawingManager'. ``` Note: `@angular/google-maps` also depends transitively on `@types/google.maps`, so the caret range floated the shared copy up to 3.65.1; the exact pin keeps both deduped at 3.64.1. ## Work required - Investigate the 3.65.x DrawingManager typing change (regression vs. intentional API surface change). - Update `marks-drawing.service.ts` to the supported pattern (e.g. `setOptions({ map })` / `setOptions({ drawingMode })`) if those methods were intentionally dropped, OR confirm a later 3.65.x patch restores them. - Remove the exact pin, restore `^3.65.x`, regenerate the lockfile. - Verify: `nx build spikersoft --configuration=production` succeeds. ## Context Pinned exact in #230's PR to prevent the lockfile from floating back to the broken typings.
Author
Owner

Investigated further — this is not a typings regression, it's a real, permanent API removal. Confirmed via Google's official deprecations page (developers.google.com/maps/deprecations, "Completed deprecations" section):

Drawing Library (May 2026) — Drawing Library functionality in the Maps JavaScript API is no longer supported. This API was deprecated in August 2025 and is unavailable as of May 2026.

@types/google.maps@3.65.x reflects this correctly: DrawingManager's class body is now completely empty (no setMap/setDrawingMode/etc. — confirmed by diffing the 3.64.1 vs 3.65.2 .d.ts), and it's marked @deprecated/decommissioned in the JSDoc. So bumping the types wouldn't just need a call-pattern tweak (setOptions instead of setMap) — google.maps.drawing.DrawingManager itself no longer functions at runtime once the app is on Maps JS API ≥3.65, which index.html's unversioned loader (maps/api/js?...&libraries=marker,drawing) will pick up by default already.

Good news on urgency: app-marks-map (MarksDrawingService's only consumer) isn't wired into app-routing.module.ts or referenced from any routed component today — it's unreachable in the live app (there's also a stray marks-map.component.backup.ts alongside it, suggesting this feature is mid-flight/parked). So this isn't an active production outage, but it is dead code sitting on a permanently-removed API, and the ticket's original "just bump the types" framing is no longer viable.

Recommendation: rescope this ticket to a real decision before touching it further:

  1. Confirm whether marks-site/drawing-on-map is still on the roadmap.
  2. If yes — replace DrawingManager with either a custom implementation using the still-supported editable Polygon/Rectangle/Circle overlay classes (setEditable(true) + event.addListener('overlaycomplete', ...)-style manual mode switching), or adopt Terra Draw (the community-recommended replacement, has a Google Maps adapter).
  3. If no — delete MarksDrawingService, marks-map.component.backup.ts, and the unrouted marks-site tree as dead code, and close this ticket as moot.

Either way the @types/google.maps pin can then move to ^3.65.x since nothing else in the codebase touches the drawing namespace. Happy to pick this up once there's a direction — let me know which way to go.

Investigated further — this is not a typings regression, it's a real, permanent API removal. Confirmed via Google's official deprecations page (developers.google.com/maps/deprecations, "Completed deprecations" section): > **Drawing Library (May 2026)** — Drawing Library functionality in the Maps JavaScript API is no longer supported. This API was deprecated in August 2025 and is unavailable as of May 2026. `@types/google.maps@3.65.x` reflects this correctly: `DrawingManager`'s class body is now completely empty (no `setMap`/`setDrawingMode`/etc. — confirmed by diffing the 3.64.1 vs 3.65.2 `.d.ts`), and it's marked `@deprecated`/decommissioned in the JSDoc. So bumping the types wouldn't just need a call-pattern tweak (`setOptions` instead of `setMap`) — `google.maps.drawing.DrawingManager` itself no longer functions at runtime once the app is on Maps JS API ≥3.65, which `index.html`'s unversioned loader (`maps/api/js?...&libraries=marker,drawing`) will pick up by default already. **Good news on urgency:** `app-marks-map` (`MarksDrawingService`'s only consumer) isn't wired into `app-routing.module.ts` or referenced from any routed component today — it's unreachable in the live app (there's also a stray `marks-map.component.backup.ts` alongside it, suggesting this feature is mid-flight/parked). So this isn't an active production outage, but it is dead code sitting on a permanently-removed API, and the ticket's original "just bump the types" framing is no longer viable. **Recommendation:** rescope this ticket to a real decision before touching it further: 1. Confirm whether `marks-site`/drawing-on-map is still on the roadmap. 2. If yes — replace `DrawingManager` with either a custom implementation using the still-supported editable `Polygon`/`Rectangle`/`Circle` overlay classes (`setEditable(true)` + `event.addListener('overlaycomplete', ...)`-style manual mode switching), or adopt Terra Draw (the community-recommended replacement, has a Google Maps adapter). 2. If no — delete `MarksDrawingService`, `marks-map.component.backup.ts`, and the unrouted `marks-site` tree as dead code, and close this ticket as moot. Either way the `@types/google.maps` pin can then move to `^3.65.x` since nothing else in the codebase touches the `drawing` namespace. Happy to pick this up once there's a direction — let me know which way to go.
Author
Owner

Re-scoping after investigation — the original ask (unpin, restore ^3.65.x) is NOT possible: the 3.65.x typings change is not a regression. Google deprecated and REMOVED google.maps.drawing.DrawingManager from the Maps JavaScript API as of v3.65 (notice embedded in @types/google.maps ≥3.65 and at developers.google.com/maps/deprecations); 3.65.2 still ships the class as an empty stub. Worse, our index.html loader had no v= parameter (weekly channel), so the marks-site drawing tools would break AT RUNTIME in production whenever weekly rolls past 3.64 — the 3.64.1 typings pin only hid this at compile time. Stopgap shipped in spikersoft-angular PR #162: loader pinned to v=3.64 so runtime and typings agree. Remaining scope for this ticket: migrate marks-drawing.service.ts off DrawingManager (custom drawing handlers over map events, or a library) — note Google retires pinned versions ~12 months after release, so this has a real deadline, roughly mid-2027. Keeping open with this new scope.

Re-scoping after investigation — the original ask (unpin, restore ^3.65.x) is NOT possible: the 3.65.x typings change is not a regression. Google deprecated and REMOVED google.maps.drawing.DrawingManager from the Maps JavaScript API as of v3.65 (notice embedded in @types/google.maps ≥3.65 and at developers.google.com/maps/deprecations); 3.65.2 still ships the class as an empty stub. Worse, our index.html loader had no v= parameter (weekly channel), so the marks-site drawing tools would break AT RUNTIME in production whenever weekly rolls past 3.64 — the 3.64.1 typings pin only hid this at compile time. Stopgap shipped in spikersoft-angular PR #162: loader pinned to v=3.64 so runtime and typings agree. Remaining scope for this ticket: migrate marks-drawing.service.ts off DrawingManager (custom drawing handlers over map events, or a library) — note Google retires pinned versions ~12 months after release, so this has a real deadline, roughly mid-2027. Keeping open with this new scope.
Author
Owner

Audited against origin/masterNOT DONE. Still pinned.

package.json:187"@types/google.maps": "3.64.1" (exact pin, no caret), alongside "@angular/google-maps": "^22.0.6" at :169 which is range-tracked.

So the deferral from #230 is unchanged: the types package is frozen at 3.64.1 while its runtime counterpart moves freely. That's the drift risk the ticket was filed for — the Angular wrapper can pick up a newer Maps surface than the typings describe.

Small note on scope, since this is 15 days old. The ticket cites the 3.65.x DrawingManager typings as the blocker. Worth re-checking whether that's still true before unpinning — @types/google.maps publishes frequently, so the specific breakage may well have been fixed upstream several versions ago, in which case this is a one-line change plus a typecheck rather than a migration.

And there's now a cheap way to verify it. When this was deferred, the repo had no reliable typecheck gate — the root tsc --noEmit was unusable across mixed project configs (#664). That changed: #824 confirmed E2a landed a per-project typecheck target inferred by tools/workspace-plugin, running nx affected -t typecheck on PRs and full run-many on pushes (main.yml:421-427). Plus the production nx build spikersoft is now a PR gate with no path filter.

So bumping the pin and pushing would give a definitive answer from CI rather than requiring a local investigation — which is a materially better position than when the deferral was made. Worth retrying on that basis.

Notes are otherwise accurate.

Audited against `origin/master` — **NOT DONE. Still pinned.** `package.json:187` — `"@types/google.maps": "3.64.1"` (exact pin, no caret), alongside `"@angular/google-maps": "^22.0.6"` at `:169` which *is* range-tracked. So the deferral from #230 is unchanged: the types package is frozen at 3.64.1 while its runtime counterpart moves freely. That's the drift risk the ticket was filed for — the Angular wrapper can pick up a newer Maps surface than the typings describe. **Small note on scope, since this is 15 days old.** The ticket cites the 3.65.x `DrawingManager` typings as the blocker. Worth re-checking whether that's still true before unpinning — `@types/google.maps` publishes frequently, so the specific breakage may well have been fixed upstream several versions ago, in which case this is a one-line change plus a typecheck rather than a migration. **And there's now a cheap way to verify it.** When this was deferred, the repo had no reliable typecheck gate — the root `tsc --noEmit` was unusable across mixed project configs (#664). That changed: **#824** confirmed E2a landed a per-project `typecheck` target inferred by `tools/workspace-plugin`, running `nx affected -t typecheck` on PRs and full `run-many` on pushes (`main.yml:421-427`). Plus the production `nx build spikersoft` is now a PR gate with no path filter. So bumping the pin and pushing would give a definitive answer from CI rather than requiring a local investigation — which is a materially better position than when the deferral was made. Worth retrying on that basis. Notes are otherwise accurate.
Sign in to join this conversation.