Astro 3.0

[matthewp]

We recently had a discussion on Discord about 3.0 to gather feedback on what people would most want to see. This is a collection of suggestions. We'll use this discussion thread to figure out which of these things we should tackle.

• Revisiting define:vars, to allow the scripts to be bundled
• Form actions
• Custom 404 rendering (ie, something like return new Response(Astro.render(FourOhFour), { status: 404 })
• Cropping support for images.
• React Refresh support
• React Server Components support
• APIs to query what content/data collections exist in a project
• Normalize built-in modules to use the astro: namespace
• CLI shortcuts (talk to @bluwy for an explanation)
• Content collections integration with CMSes
• Reducing astro install size by removing dependencies
• Splitting astro add into a separate package to lazily install.
• Update endpoints to use export const GET | POST | PUT | DELETE (all uppercase) to match Next, SvelteKit, etc.
• Expose a way to generate unique IDs for elements inside a component and access them on the client. For example, Astro.hash or Astro.id("my-prefix")
• Better unit testing support for Astro components
• Container API
• Astro.cookies.get(name) always returns an object. Make it return undefined if there is no cookie.
• Make getCollection() always return a fresh array. getCollection() should always return fresh array #604
• Draft previews. Preview draft content from CMSs in static sites (think: Next.js Preview Mode) #564
• Provide the logger to integrations
• Introduce an astro:env module rather than relying on import.meta.env inlining
  • Expose BROWSER and DEV variables to clarify the environment certain modules run in
  • Possibly introduce PRERENDER variable
  • Move import.meta.env values to this module
• Allow adapters to tell Astro what features they support, so Astro can provide good error messages when using options with adapters that do not support them.

[RaphaelBossek]

• Better unit testing support for Astro components: I hope this will consider RFC Interface to Create Fixture-based Astro Test Environment #576
• Provide the logger to integrations: I also appreciate this from plugin development perspective

Will Container API: render components in isolation (#533) be part of the 3.0 roadmap ?

[matthewp]

Will **Container API: render components in isolation** (#533) be part of the 3.0 roadmap ?

That's still being decided. So far this is a list of what people have most asked for. I think we'd like to do the Container API and have previously planed to work on it; so if it makes 3.0 is mostly about timing and team bandwidth.

[fprl]

• Form actions
• Server functions (not there, I know sorry)
• Revisiting define:vars, to allow the scripts to be bundled
• Custom 404 rendering
• Better unit testing support for Astro components
• Container API

Form actions are really important IMO and fits perfectly with Astro's philosophy of using the platform and avoiding JavaScript whenever possible. Also, is one of the missing features — with some kind of client-side router (in progress?) — to fully dive into Astro for building web apps

PS: IMO, Qwik implementation with Zod is the best DX.

[shishkin]

Would it be possible to move to TypeScript moduleResolution: "node16" in 3.0?

[Princesseuh]

Yep, we're planning to move to moduleResolution: 'bundler' for 3.0, which unlocks the same benefits!

[shishkin]

The biggest improvement for a major version would be a combination of:

• allowing to write top-level pages in any Astro-supported framework;
• allow to pass Astro components around as JSX;
• allow nesting of islands like static -> island -> static -> island.

[fweth]

I think scoped query selectors would be awesome. Since Astro already adds hashes to class names in order to enable scoped CSS, it would be awesome if something like Astro.querySelector("a") would work to select only the hrefs in the current scope.

[louiss0]

Can we get Generic Components #601. I'm not trying to pressure anyone but no one seems to care about this concept but me. Generic Components are useful for composition and logic reuse.

[HomWang]

State sharing between servers and clients. When I store the state on the server and retrieve it on the client.

Now E.g:
Server: a.astro

---
import { LangAtom } from "@/store/state";
LangAtom.set("en");
---

Client: a.tsx(React、Vue、Other)

import { LangAtom } from "@/store/state";
LangAtom.get(); // undefined

Expect E.g:
Server: a.astro

---
import { LangAtom } from "@/store/state";
LangAtom.set("en");
---

Client: a.tsx(React、Vue、Other)

import { LangAtom } from "@/store/state";
LangAtom.get(); // "en"

[HomWang]

Need a spa page for fallback.html
Condition established:
1.Server failed
2.Client SSG Dynamic routing not found
3.Enable 'fallback. html' to make up for Dynamic routing that SSG cannot find

[HomWang]

client-side HTML and server-side HTML.
E.g:
a.client.astro
and
b.server.astro

[louiss0]

I'd like to also add functional components.

Typed slots.