Bug: Astro.locals.netlify is untyped

[nickytonline]

Astro Info

Astro                    v4.3.5
Node                     v20.11.0
System                   macOS (arm64)
Package Manager          npm
Output                   server
Adapter                  @astrojs/netlify
Integrations             @astrojs/tailwind

Describe the Bug

Currently, if you are deploying to Netlify, you have access to platform features there such as geo location information.

What's the expected result?

I'd expect the types for Astro.locals.netlify to be defined.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-ewmpks

Participation

• [X] I am willing to submit a pull request for this issue.

[nickytonline]

Happy to put up a PR for this. Declaration merging is the way I'd go. I'd suggest adding the types in https://github.com/withastro/adapters/blob/main/packages/netlify/src/types.d.ts, this way only projects that deploy to Netlify would get the types.

declare namespace App {
  export interface Locals {
    netlify: {
      context: {
        geo: {
          timezone: string
          city: string
          country: string
          latitude: number
          longitude: number
        }
      }
    }
  }
}

Here it is working in my local project.

[alexanderniebuhr]

Thanks for the report. Usually users type Astro.locals themselves, so I don't know if this should be done by the adapter. I'll asked others to weigh in.

[nickytonline]

The reason why I'm suggesting it is that the adapter is for a specific platform, so why not expose the types for that platform? And via declaration merging, someone in user land could extend it further if they needed to.

[alexanderniebuhr]

We discussed this on our Discord in the open channel for contribution. For the time being we do recommend typing manually. But there is a interface you can extend, which is documented here: (https://docs.astro.build/en/guides/integrations-guide/netlify/#accessing-edge-context-from-your-site)

We faced some limitations in the past with your suggested approach, but will look into this in the future again.

[alexanderniebuhr]

I'm closing this issue, since our position has not changed. If anything changes, we can reopen this in the future :)