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.
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.
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:
Confirm whether marks-site/drawing-on-map is still on the roadmap.
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).
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.
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.
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Split out from #230 (frontend app-runtime libraries roll-up).
@types/google.mapswas excluded from the bump and pinned to3.64.1(exact, no caret) because 3.65.x breaks our build.Problem
@types/google.maps@3.65.1removessetMapandsetDrawingModefrom thegoogle.maps.drawing.DrawingManagertype. The production build fails inprojects/spikersoft/src/app/_services/marks-site/marks-map/marks-drawing.service.ts:Note:
@angular/google-mapsalso 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
marks-drawing.service.tsto 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.^3.65.x, regenerate the lockfile.nx build spikersoft --configuration=productionsucceeds.Context
Pinned exact in #230's PR to prevent the lockfile from floating back to the broken typings.
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):
@types/google.maps@3.65.xreflects this correctly:DrawingManager's class body is now completely empty (nosetMap/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 (setOptionsinstead ofsetMap) —google.maps.drawing.DrawingManageritself no longer functions at runtime once the app is on Maps JS API ≥3.65, whichindex.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 intoapp-routing.module.tsor referenced from any routed component today — it's unreachable in the live app (there's also a straymarks-map.component.backup.tsalongside 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:
marks-site/drawing-on-map is still on the roadmap.DrawingManagerwith either a custom implementation using the still-supported editablePolygon/Rectangle/Circleoverlay classes (setEditable(true)+event.addListener('overlaycomplete', ...)-style manual mode switching), or adopt Terra Draw (the community-recommended replacement, has a Google Maps adapter).MarksDrawingService,marks-map.component.backup.ts, and the unroutedmarks-sitetree as dead code, and close this ticket as moot.Either way the
@types/google.mapspin can then move to^3.65.xsince nothing else in the codebase touches thedrawingnamespace. Happy to pick this up once there's a direction — let me know which way to go.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.
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:169which 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
DrawingManagertypings as the blocker. Worth re-checking whether that's still true before unpinning —@types/google.mapspublishes 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 --noEmitwas unusable across mixed project configs (#664). That changed: #824 confirmed E2a landed a per-projecttypechecktarget inferred bytools/workspace-plugin, runningnx affected -t typecheckon PRs and fullrun-manyon pushes (main.yml:421-427). Plus the productionnx build spikersoftis 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.