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

Closed
opened 2026-06-17 04:57:46 +00:00 by spikerj · 4 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/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.

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.
Author
Owner

Migrated to spikerj/spikersoft-angular#643 as part of the umbrella-tracker breakup.

Verified 2026-08-07 against spikersoft-angular@8e5a404, and live against the deployed main-KZKZUOSX.js bundle on learn.spikersoft.com.

  • Code: Still pinned. package.json:187 — "@types/google.maps": "3.64.1" (exact, no caret), next to "@angular/google-maps": "^22.1.0" at :169. The stopgap from the 2026-07-11 re-scope is also still in place: projects/spikersoft/src/index.html:80 loads maps/api/js?...&v=3.64&libraries=marker,drawing. The removed API is still called: _services/marks-site/marks-map/marks-drawing.service.ts:17,:67 construct google.maps.drawing.DrawingManager and :95,:109,:149 call setDrawingMode().
  • Live: marks-site remains unreachable, as the 2026-07-01 comment reported: rg marks over app-routing.module.ts → 0 hits, nothing named marks* appears in the prod main-KZKZUOSX.js route table, and MarksAddressComponent's only non-spec reference is its own .stories.ts. So this is not a live outage — it is dead code sitting on a permanently-removed Google API.

Status: not done — Everything, at the re-scoped definition: (1) decide whether marks-site drawing stays; (2) if it stays, migrate marks-drawing.service.ts off DrawingManager onto editable Polygon/Rectangle/Circle overlays or Terra Draw; if it goes, delete the service, marks-map.component.backup.ts and the unrouted tree; (3) then drop the 3.64.1 pin to ^3.65.x and remove the v=3.64 loader pin. Google retires pinned versions ~12 months after release, so the v=3.64 stopgap expires around mid-2027. Per the 2026-07-29 comment, the repo now has a per-project typecheck target plus a production nx build spikersoft PR gate, so the unpin can be validated by CI rather than locally.

Closing here. Work now lives in the repo that holds the fix, so fixes #643 in a PR will auto-close it on merge. The umbrella tracker keeps cross-repo epics only.

— Opus 5 Agent

Migrated to **spikerj/spikersoft-angular#643** as part of the umbrella-tracker breakup. Verified 2026-08-07 against `spikersoft-angular@8e5a404`, and live against the deployed `main-KZKZUOSX.js` bundle on learn.spikersoft.com. - **Code:** Still pinned. `package.json:187` — `"@types/google.maps": "3.64.1"` (exact, no caret), next to `"@angular/google-maps": "^22.1.0"` at `:169`. The stopgap from the 2026-07-11 re-scope is also still in place: `projects/spikersoft/src/index.html:80` loads `maps/api/js?...&v=3.64&libraries=marker,drawing`. The removed API is still called: `_services/marks-site/marks-map/marks-drawing.service.ts:17,:67` construct `google.maps.drawing.DrawingManager` and `:95,:109,:149` call `setDrawingMode()`. - **Live:** marks-site remains unreachable, as the 2026-07-01 comment reported: `rg marks` over `app-routing.module.ts` → 0 hits, nothing named `marks*` appears in the prod `main-KZKZUOSX.js` route table, and `MarksAddressComponent`'s only non-spec reference is its own `.stories.ts`. So this is not a live outage — it is dead code sitting on a permanently-removed Google API. Status: **not done** — Everything, at the re-scoped definition: (1) decide whether marks-site drawing stays; (2) if it stays, migrate `marks-drawing.service.ts` off `DrawingManager` onto editable `Polygon`/`Rectangle`/`Circle` overlays or Terra Draw; if it goes, delete the service, `marks-map.component.backup.ts` and the unrouted tree; (3) then drop the `3.64.1` pin to `^3.65.x` **and** remove the `v=3.64` loader pin. Google retires pinned versions ~12 months after release, so the `v=3.64` stopgap expires around mid-2027. Per the 2026-07-29 comment, the repo now has a per-project `typecheck` target plus a production `nx build spikersoft` PR gate, so the unpin can be validated by CI rather than locally. Closing here. Work now lives in the repo that holds the fix, so `fixes #643` in a PR will auto-close it on merge. The umbrella tracker keeps cross-repo epics only. — Opus 5 Agent
Sign in to join this conversation.