astro: namespace for middleware and components

[matthewp]

Changes

• Adds aliases of astro:middleware and astro:components

Testing

• All updated to use the aliases

Docs

• PR

[changeset-bot]

🦋 Changeset detected

Latest commit: fdbf0c4

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

This PR is blocked because it contains a minor changeset. A reviewer will merge this at the next release if approved.

[Princesseuh]

It's a side quest not really related to this, but someone (me, probably) should make it so imports starting with astro: gets prioritized in the language-tools, otherwise when you type like <Code> it'll auto import from astro/components first

[ematipico]

About astro:middleware VS astro/middleware, here's some concerns we should take into account (even in the language tools cc @Princesseuh )

At the moment, astro/middleware exposes the following APIs: createContext, trySerializeLocals, defineMiddleware and sequence.

defineMiddleware and sequence can be part of astro:middleware, but createContext, trySerializeLocals can't be part of astro:middleware, because are runtime APIs that expose code that will be used by integrations for advanced features (e.g. edge middleware).

I wonder:

• is it possible to exclude createContext, trySerializeLocals from astro:middleware?
• is it possible to exclude defineMiddleware and sequence from astro/middleware?
• is it possible to suggest the correct import based on the context? Probably yes, because the middleware is a known file with fixed location and name.

[ematipico]

Suggested change

	`astro:`namespace aliases for middleware and components
	`astro:` namespace aliases for middleware and components

[bluwy]

but createContext, trySerializeLocals can't be part of astro:middleware, because are runtime APIs that expose code that will be used by integrations for advanced features (e.g. edge middleware).

Couldn't createContext and trySerializeLocals still be part of astro:middleware, but integrations can import from astro/middleware instead? They'd be unused in the other environments, but I think it's probably fine so it's easier to maintain.

[matthewp]

It's easy enough to create another module to use as the alias so I'll do that.

[ematipico]

but createContext, trySerializeLocals can't be part of astro:middleware, because are runtime APIs that expose code that will be used by integrations for advanced features (e.g. edge middleware).

Couldn't createContext and trySerializeLocals still be part of astro:middleware, but integrations can import from astro/middleware instead? They'd be unused in the other environments, but I think it's probably fine so it's easier to maintain.

As long as the functions are correctly bundled by esbuild, it's fine by me.