Make Astro global available outside of *.astro files

[mirkonasato]

I just started playing with Astro, so do let me know if I'm missing something.

The docs mentions that the Astro global is available in *.astro files. What I didn't expect is that it's only available there. It doesn't seem possible to extract any code that uses it to a separate file.

Let's take the blog sample: it would be nice to extract the logic that calls Astro.glob() and then sorts the posts into a separate getPosts function, maybe in a src/lib/posts.js module. That doesn't work: Astro there is undefined, even if the function that uses it is called from an *.astro file.

Passing the Astro instance as an argument when calling getPosts function doesn't work either: this results in a fn is not a function error.

The only solution I could find was to use Node.js Builtins to get the list of posts rather than using the Astro global, which is the opposite of what the docs recommend.

Is there any way to make the Astro global available outside of *.astro files?

[olimination]

We had recently the same question. We currently have the "workaround" that we do the Astro.glob() logic stuff still in the *.astro file (usually just 2 lines of code) and pass the list of results into some separate Javascript object/function as parameter. With this we could consolidate the needed logic for some domain into a separate object and just have this Astro.glob() logic duplicated on several places, which is still not very optimal.

I think having some possibility to access the global Astro object from everywhere in the JS source would be a great benefit to improve code structure.

[brycewray]

I will chime in with my oft-noted whine 😄 — if this could be used for non-HTML files, would allow better creation of RSS and JSON feeds — especially the latter, since the JSON Feed spec requires HTML content but, without Astro.glob(), you can’t get the results of components when getting content.

[mirkonasato]

I see some new and interesting things in the docs: a note mentions that

Astro.glob() is a wrapper of Vite’s import.meta.glob()

and the RSS guide shows an example of using said import.meta.glob() directly:

const postImportResult = import.meta.glob('../posts/**/*.md', { eager: true });
const posts = Object.values(postImportResult);

So I guess the same approach could be used in any file.

[brycewray]

@mirkonasato I think the question is whether this extracts the correct HTML from an Astro component, rather than just (e.g.) <MyComponent /> — such as a JSON feed, the spec for which requires the HTML from a page. As of some weeks ago, it didn't. It's somewhat of a niche-y use case, I concede.

[schlichtanders]

I am also running into the wish to have a Astro global object outside of .astro files

for me it is .mdx files which I would like to combine with dynamic routing. However, Astro.params seems to be the only way to access the params from dynamic routes.

Hence also here you currently need to create an extra .astro file as a workaround to pass the Astro.params information via props.
MDX also supports jsx, hence a generic Astro global variable would make a lot of sense

[misl-smlz]

We have the same problem with Astro.request.headers. We want to use it in a middleware in openapi-fetch in a simple *.ts file. Is there any way to access Astro.request in a *.ts file other than via function parameters?

[Fryuni]

Astro.request only exists during a request. That is when your endpoint function is called, and the request is passed inside the context argument.

Outside of that function call, what would be the value of the request? There is nothing to be there.

In an Astro component, you only write the portion of the code that runs per request, so it can be provided as a global. ¹

In an arbitrary *.ts file, you could run things outside of a request, which would require adding runtime checks to detect that and throw an appropriate error instead of a cryptic error:

// This runs outside of any request; there is no sensible value to read here.
const requestURL = Astro.request.url;

export const GET = (context) => {};

As I said, this would require runtime validations, which the Astro team decided to avoid. But that has been implemented as a third-party integration called astro-global. It allows you to use the values of the Astro global anywhere at the cost of doing a runtime check to see which request, if any, is being processed on every access.

Footnotes

1. Fun fact, it is not even a global. The Astro compiler injects a const Astro = ... in the generated function, constructed from the arguments just like the endpoints. ↩

[misl-smlz]

Cool. Thank you very much for your detailed explanation.

[abegehr]

A use-case for Astro global in script files (and component framework files) would be sharing variables like Astro.url or Astro.currentLocale throughout the server-side-rendered application. I came across this while trying to make a framework component that uses window.location.pathname to render on SSR via Astro. It was using window.localtion.pathname to get the current locale for i18n. Is it a valid solution to use a server-side nanostore for a Astro.currentLocale global variable or will this mix up languages between requests in SSR? See https://stackoverflow.com/a/78751096/499113 for more details.

[vincerubinetti]

This would be great. I have a getData function that needs to import and parse a local JSON file, but that function is needed on several different pages. I want to extract that logic into a separate .js script so I can just re-use it from there.

Or I suppose another solution could be if astro components could export things.

[Princesseuh]

What does your getData function needs from the Astro global?