|
| 1 | +--- |
| 2 | +"@object-ui/plugin-map": patch |
| 3 | +"@object-ui/plugin-ai": patch |
| 4 | +"@object-ui/plugin-report": patch |
| 5 | +"@object-ui/plugin-dashboard": patch |
| 6 | +"@object-ui/create-plugin": patch |
| 7 | +"@object-ui/console": patch |
| 8 | +--- |
| 9 | + |
| 10 | +fix(plugin-map): drop the `maplibre-gl@6` default import, and put type-check behind a CI gate that cannot be silently skipped (#2911) |
| 11 | + |
| 12 | +`maplibre-gl@6.0.0` removed its default export (arrived via #2848, dependabot), |
| 13 | +so `ObjectMap.tsx`'s `import maplibregl from 'maplibre-gl'` has been a TS1192 |
| 14 | +error on `main` for a day. The binding was never used — the map instance comes |
| 15 | +from `react-map-gl/maplibre`, and the stylesheet from the side-effect import on |
| 16 | +the next line — so the import is simply deleted rather than rewritten to |
| 17 | +`import * as`. |
| 18 | + |
| 19 | +Removing it is runtime-neutral, which the issue had explicitly left unverified. |
| 20 | +`@vis.gl/react-maplibre` (what `react-map-gl/maplibre` re-exports) does |
| 21 | +`Promise.resolve(mapLib || import('maplibre-gl'))` in `components/map.js`, so it |
| 22 | +loads the library itself when no `mapLib` prop is passed. Verified in a browser |
| 23 | +against the `store-locator-map` catalog schema: `maplibre-gl` is fetched as its |
| 24 | +own lazy chunk, the WebGL canvas comes up 800x600, and all three markers mount — |
| 25 | +byte-identical probe output with and without the static import. That also matches |
| 26 | +what `apps/console/src/main.tsx` already intends, where the plugin is registered |
| 27 | +lazily specifically to keep `maplibre-gl` out of the initial bundle. |
| 28 | + |
| 29 | +**The reason it survived a day of green CI is the part worth fixing.** No |
| 30 | +workflow ran `type-check` at all, and `turbo build` only checks types for |
| 31 | +packages whose `build` script happens to invoke `tsc` — the 22 `vite build` |
| 32 | +packages transpile without checking. A sweep of all 45 packages found ten with |
| 33 | +broken types, `plugin-map` merely being the one that had a script to notice it. |
| 34 | + |
| 35 | +Adding a `pnpm type-check` job alone would not have been a gate: **turbo silently |
| 36 | +skips any package with no `type-check` script**, so 17 packages read as passing |
| 37 | +because nothing ran. With `plugin-map` fixed, `pnpm type-check` reports 63/63 |
| 38 | +green while nine packages are still broken. So: |
| 39 | + |
| 40 | +- `plugin-ai` and `plugin-report` gain the `paths` override their type-checked |
| 41 | + peers already carry, which detaches workspace deps from sibling *source* and |
| 42 | + resolves them through built `.d.ts` — the sole cause of the 104-error TS6059 |
| 43 | + `rootDir` floods, and the same trick their own `vite.config.ts` already applies |
| 44 | + to the dts program. |
| 45 | +- Seven packages gain `"type-check": "tsc --noEmit"` (`plugin-ai`, |
| 46 | + `plugin-report`, `plugin-dashboard`, `create-plugin`, `console`, and the two |
| 47 | + console examples). Coverage goes 28 -> 35 of 45. |
| 48 | +- New `scripts/check-type-check-coverage.mjs` makes the invisibility impossible: |
| 49 | + a package with no `type-check` script must be declared, with a reason, and the |
| 50 | + lists only shrink — gaining a script without deleting the entry fails the |
| 51 | + guard. The nine known-broken packages are recorded there with error counts |
| 52 | + (`@object-ui/runner` has no `tsconfig.json` at all), tracked as follow-ups. |
| 53 | +- New `Type Check` CI job runs the coverage guard first (instant, no install), |
| 54 | + then `pnpm type-check`. |
| 55 | + |
| 56 | +Both halves were proven to fail before being trusted: the guard was exercised in |
| 57 | +all four of its failure modes, and re-introducing the `maplibre-gl` import turns |
| 58 | +the job red again, as does a fresh error injected into `plugin-ai` — a package |
| 59 | +that had no type checking whatsoever before this change. |
0 commit comments