fix: Upgrade mapbox-gl

[AliceR]

I am attempting to upgrade mapbox-gl, in order to use the fitBounds with alternative projections. Version 3.5 introduces breaking changes to the type system, which I was able to address in e227a9d. I have some issues left that I need help with, also need someone with better understanding of our veda typings to have a proper look at my changes.
@sandrahoang686 maybe? 😊

[netlify]

✅ Deploy Preview for veda-ui ready!

Name	Link
🔨 Latest commit	e40b575
🔍 Latest deploy log	https://app.netlify.com/sites/veda-ui/deploys/679b5a16cb583800076b6afc
😎 Deploy Preview	https://deploy-preview-1400--veda-ui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[dzole0311]

@AliceR I think the issue is a mismatch between the ProjectionOptions in veda.ts and ProjectionOptions in index.d.ts 🤔 Updating the one in the module definition file (parcel-resolver-veda/index.d.ts) seems to resolve the TS errors:

  export type ProjectionOptions = {
    id: mapboxgl.ProjectionSpecification['name'] | 'polarNorth' | 'polarSouth';
    parallels?: number[];
    center?: [number, number];
  };

[AliceR]

Thanks @dzole0311 , this indeed fixed all the ts errors. I am still not sure if I solved all the issues correctly... And now I even wonder why we have this duplication between app/scripts/types/veda.ts and parcel-resolver-veda/index.d.ts... 🤔

[sandrahoang686]

hey @AliceR 👋🏼 . Just saw your question in the description but what could I help out with specifically when it comes to typing? There is lots going on with it and much improvement in our codebase needed for it 😄 . A few things I can summarize right now though that might help out..

1. When it comes to casting, (someType as otherType) this generally isn't good practice because it means we are masking ill defined type interfaces or bad transformations or dont have the correct types. There is actually already a good amount of this happening in the veda-ui codebase which has been noted as tech-debt (a tech-debt ticket here). Looks like a good amount of casting is going on in this PR as well which means we should probably look at the type definitions and clean it up
2. Like Hanbyul mentioned, we want to decouple from veda virtual modules so any types under parser-resolver-veda/* we wont want to use and should use $types/veda. Most types exist there already I believe, if not, we'd just want to copy them over
3. If we want types to be exposed to the NextJs instance to use, these types of have to defined in a *.ts file instead of a *.d.ts file. Context from this PR here.

lmk if I could help assist in any of these areas :)

[AliceR]

Thank you for the context @sandrahoang686 , it makes a lot of sense!

The only thing missing here then would be a review decision: can this PR be merged as is, and if not, which of the tech debt should we include?

[AliceR]

Spread types may only be created from object types.ts(2698)

const projection: MbProjectionOptions

[dzole0311]

Suggested change

	...(generatorLayer.metadata ?? {}),
	...generatorLayer.metadata

[dzole0311]

Oops, this will only work if we don't pass unknown to the metadata?: ExtendedMetadata.

[AliceR]

Should we create a tech debt ticket to clean up typings around maps/sources/metadata? This seems to be a bit of a 🧶 (alt: a knotty situation)