What happened?
NEXT_PUBLIC_GOOGLE_MAPS_API_KEY is documented in two places but has no consumer anywhere in the repo. Someone following setup will provision a Google Cloud API key, enable billing on it, and get nothing — with no way to tell whether they misconfigured something or the feature doesn't exist.
Where it's documented:
SETUP.md:26 — table row: `NEXT_PUBLIC_GOOGLE_MAPS_API_KEY` | No | Enables address search in the editor.env.example:4 — # NEXT_PUBLIC_GOOGLE_MAPS_API_KEY=your_google_maps_api_key
Where it's read: nowhere. Grepping GOOGLE_MAPS and googleapis across packages/*/src and apps/editor returns only those two doc lines. There's no address-search or geocoding UI in the editor either, and no map/geocoding provider is wired up at all — so the row doesn't describe a feature that's merely unconfigured, it describes one that isn't present.
The No in the required column keeps this from blocking anyone, which is presumably why it survived. But it's the kind of doc rot that costs a new contributor real time and a little money, and it makes the rest of the setup table less trustworthy.
Expected behavior
Setup docs list env vars the code actually reads.
Suggested fix
Delete both lines. Two lines, no code change, no behaviour change — a genuine good-first-issue.
Please do not "fix" this by implementing Google-backed address search to justify the key. If address search is wanted later, the provider choice needs its own discussion first: Google's Maps Platform terms are restrictive for this use case (notably, deriving or storing geographic data from their responses), and there are provider options — for example IGN data.geopf.fr for France, or Nominatim for general geocoding — that fit an open-source editor better. That's a design conversation, not a cleanup task.
Additional context
Found during a maintainer housekeeping pass. Related: whether the editor should have any first-party geocoding is open — see #154 (map support), which is the right place for that discussion.
What happened?
NEXT_PUBLIC_GOOGLE_MAPS_API_KEYis documented in two places but has no consumer anywhere in the repo. Someone following setup will provision a Google Cloud API key, enable billing on it, and get nothing — with no way to tell whether they misconfigured something or the feature doesn't exist.Where it's documented:
SETUP.md:26— table row:`NEXT_PUBLIC_GOOGLE_MAPS_API_KEY` | No | Enables address search in the editor.env.example:4—# NEXT_PUBLIC_GOOGLE_MAPS_API_KEY=your_google_maps_api_keyWhere it's read: nowhere. Grepping
GOOGLE_MAPSandgoogleapisacrosspackages/*/srcandapps/editorreturns only those two doc lines. There's no address-search or geocoding UI in the editor either, and no map/geocoding provider is wired up at all — so the row doesn't describe a feature that's merely unconfigured, it describes one that isn't present.The
Noin the required column keeps this from blocking anyone, which is presumably why it survived. But it's the kind of doc rot that costs a new contributor real time and a little money, and it makes the rest of the setup table less trustworthy.Expected behavior
Setup docs list env vars the code actually reads.
Suggested fix
Delete both lines. Two lines, no code change, no behaviour change — a genuine good-first-issue.
Please do not "fix" this by implementing Google-backed address search to justify the key. If address search is wanted later, the provider choice needs its own discussion first: Google's Maps Platform terms are restrictive for this use case (notably, deriving or storing geographic data from their responses), and there are provider options — for example IGN
data.geopf.frfor France, or Nominatim for general geocoding — that fit an open-source editor better. That's a design conversation, not a cleanup task.Additional context
Found during a maintainer housekeeping pass. Related: whether the editor should have any first-party geocoding is open — see #154 (map support), which is the right place for that discussion.