Fixed
latandlngno longer lose precision. Coordinates were being rounded on write on MySQL, PostgreSQL and SQL Server.
Laravel 11 narrowed Blueprint::float() from float($column, $total, $places) to float($column, $precision = 53). PHP does not error on extra positional arguments to a userland method, so $table->float('lat', 10, 8) silently discarded the 8 decimal places and set the precision to 10.
A precision of 10 falls in the single-precision band on every driver that honours it: float(10) yields a 4-byte column of roughly 7 significant digits on MySQL, real on PostgreSQL, and a 4-byte real on SQL Server. A coordinate like 40.71277800 needs 10 significant digits, so the stored value was rounded. Dropping the stale arguments restores the default precision of 53, which maps to double / double precision and stores these values exactly.
SQLite is unaffected — it emits a bare float either way and stores the full double regardless. That is also why the test suite never caught this, and still cannot: the suite runs on SQLite, so the generated DDL is the only meaningful verification.
There is no compatibility risk in the change itself. maatwebsite/excel ^4.0 requires illuminate/support: ^12.0 || ^13.0, so this package is only installable on Laravel 12 or 13, and both carry the narrowed signature. Laravel 10 — the last version whose float() accepted (total, places) — is not reachable.
Anyone on v1.0.1 or earlier running against MySQL, PostgreSQL or SQL Server has coordinates stored at reduced precision. This release corrects the schema for new installs only. An existing table keeps its narrow columns, and the values already written to it were rounded at insert time, so recovering them means widening the columns and re-importing the source data — an ALTER alone will not bring the digits back.