- What does petrepatrasc/google-map actually do?
- It is an object-oriented PHP builder for the client-side Google Maps JavaScript API v3. Despite the API v3 integration description, it does not call Google's web services; it models map entities such as Map, Marker, InfoWindow, Polyline, Polygon, and KmlLayer and renders them as HTML and JavaScript. You echo that output into a view and the browser draws the map. Treat it as a view-layer code generator, not a data-access layer.
- How do I install and use it in a Laravel application?
- Pull it in with Composer and render the generated markup from a Blade view, typically with an unescaped output tag. The package ships no service provider, facade, or config file, so there is nothing to register in Laravel's container. Verify autoloading first, because the library predates PSR-4 and may need a classmap entry or namespace adjustment. Test the output against your Content Security Policy before shipping.
- Does it support Laravel 11 and PHP 8.2 or 8.3?
- PHP version support is unstated and the code is frozen at a PHP 5.3-era idiom, so 8.2 and 8.3 compatibility is not guaranteed. Expect possible use of constructs removed in PHP 8, such as each(), create_function, and curly-brace string offsets. Run the renderer under E_ALL on your target version and patch whatever breaks. Plan on treating this as a small, auditable fork rather than a drop-in dependency.
- Do I need a Google Maps API key to use this package?
- Yes. The library only generates client-side JavaScript, so you must load the Google Maps JavaScript API yourself with your own key. Since 2018 that key requires an associated billing account, and an unrestricted key is a direct financial exposure. Apply HTTP referrer restrictions, API restrictions, and per-API quota caps. The package offers no guidance or guardrails here, so key management is entirely your responsibility.
- Can I use it for server-side geocoding, directions, or Places lookups?
- No. It is a renderer for the Google Maps JavaScript API v3 and does not implement server-side clients for Geocoding, Directions, Places, or Distance Matrix. If you need server-side geodata, call Google's web services directly with an HTTP client and keep that in your domain or infrastructure layer. Use this package only for drawing the map in the browser.
- How do I render a map in a Blade template?
- Build the map object graph in PHP and echo the rendered output in Blade with an unescaped tag. Keep that construction behind a Blade component or a small view-model instead of placing it in domain services or queued jobs. Because the package emits inline script blocks, watch ordering relative to your other assets. A thin wrapper keeps the rest of the codebase clean if you later swap the library out.
- Will this package break my Content Security Policy?
- It can, and this is the main integration friction. The library emits inline script blocks, which conflict with a nonce- or hash-based CSP unless you patch the renderer to accept and output a nonce. You may also hit asset ordering assumptions in your layout. Budget time for a small renderer fork or a strict-dynamic policy.
- Does it support AdvancedMarkerElement, or is google.maps.Marker deprecated?
- Almost certainly not. The package's Marker class almost certainly emits the classic google.maps.Marker, which is deprecated in favor of AdvancedMarkerElement. AdvancedMarkerElement requires a Map ID and a different construction path, while other legacy overlays and controls accumulate deprecation warnings. If you need AdvancedMarkerElement, cloud-based map styling, or Map IDs, the Marker abstraction is already obsolete and you would be writing a wrapper around it.
- Is it safe to run in production, given the package has no stars or maintainers?
- Dependency risk is high but bounded: zero stars, zero dependents, no CVE response channel, and no compatibility patch cadence. The code is small enough to audit and fix in hours, but that becomes your maintenance burden indefinitely. Production use is defensible only if you own the fork, pin the version, and define a retirement trigger such as falling two PHP minor versions behind. Also budget for drift in the underlying Google Maps JavaScript API.
- What are the alternatives if I only need a few map features?
- You can hand-write a small map init script, use a maintained JavaScript-side library, or fork this package and keep only the classes you need, likely Map, Marker, InfoWindow, and Polyline. If the required surface is five classes, the fork burden is trivial and the adoption case improves. Decide the trigger for retiring that fork before you commit.