[Planning] What should we work on next?

[FredKSchott]

Hey all! With last week's release behind us, we're beginning to discuss a potential post-v1.0 roadmap for the project.

But, we need your help:

• Q: What do you think should be worked on next?
• Q: Is there a feature that is causing you trouble, that you want to see improved?
• Q: A confusing feature?
• Q: A missing feature?

If something isn't mentioned here, we might not get to it! We'll be looking for feedback from this thread, our open issue tracker on GitHub, and the #support-threads channel in Discord. We'll combine all that data together to come up with a tentative post-v1.0 roadmap for the project, to be discussed.

Notes:

• This thread should be for overall roadmap planning, and not for digging into any specific feature. If you'd like to dig deep into a specific feature or change, but sure to use a breakout RFC discussion thread to do that.
• Include any links to separate, breakout RFC discussion threads if they exist!
  -We're still less than a week out from the v1.0 release, and our immediate focus continues to be v1.0 stability. There's plenty to keep us busy in that department for the next few weeks, so consider this discussion more future, forward-looking.

---

Update, 29 August

Thanks everyone for leaving feedback! I've read every comment left so far, and I've summarized the top 10 requests that I've seen here into a poll in our Discord #vote channel to help rank them by interest. The Astro Maintainers and Core team will use this to help inform our post v1.0 roadmap over the next week or so, with a goal of publishing a public roadmap once it's ready.

If you have a second, please vote! (#vote channel in sidebar)

[Olyno]

Hi 👋🏻

This is something I would love to see on my end: Youtube tutorials. We can take Redwood's youtube channel as an example.

The tutorials can be focused on many topics, such as stores, markdown.... The goal is to have tutorials that are not too long (between 10 and 20 minutes). They can also be split in several episodes.

Some ideas:

• Create a blog
• Create a forum
• Create a todo list

[dselles]

I second this. A rich, thoughtful tutorial ecosystem would be a major help (and selling point) for the platform, and as a novice user it's something I've really been missing. I feel like I need some additional guidance beyond the docs when it comes to really tapping into all that Astro is capable of, beyond its most basic concepts.

[mayank99]

3 biggest missing features off the top of my head:

• Ability to pass functions as props: The .astro file syntax feels super nice to author in, but I often find myself moving the markup to framework components because there is no way to use functions as props. This feels even more frustrating because you cannot mix & match frameworks (or use Astro components) once you leave the .astro file.
• Page-level SSR runtime: Currently there is no way to choose between static vs node SSR vs edge SSR at a page level; it can only be done for the whole site.
• More server-side helpers: Request/Response/redirect is a very good start but it would be nice to have more helpers for things like cookies, sessions, middleware, as well as mutations ("actions"). Also it would be nice to be able access these outside an astro file.

[ppkehl]

Page level SSR runtime would be amazing!

[CanRau]

Came here to mention mutations (actions) and have to agree with all of your suggestions 🙌

[tanepiper]

Numbers 1 and 2 are essential

1. We've also found that the more we write things, the more we move away from Astro components - really seeing this as a MVVM model where the Astro components are just templates, and all the business logic is moved to Svelte components - opens up a question "Why aren't we just using SvelteKit instead?"

2. We don't use Astro's SSR at the moment, for this reason, although we are looking at the architecture of Astro mini-sites all running on the same domain separated by paths. If we had page-level SSR, we could keep a single site and work this way.

[sandervspl]

Overall the DX is pretty good. There are still a few things that I thought would be fixed with v1 but sadly wasn't. Most of it is just stability improvements. These are from the top of my head. Not at a computer atm.

DX:

• Importing components sometimes triggers TS errors for seemingly no reason. For .astro files: no default export found. For Preact components: most of the times I can omit the .tsx extension in the import. In rare occasions I can't. Sometimes that still gives me errors. Only a ts-ignore helps in this case.
• the dev-server crashes completely when you import a file that doesn't exist anymore, for example. This is quite jarring during development. I can't remember this happening with Next for example.

Improvements:

• Importing and using .astro files in framework component files. I've often found myself having to rewrite .astro files into framework components, and sometimes these would also use .astro files so I have to rewrite multiple files so I can use a component in framework files. This almost makes me feel like rewriting all components into framework components. That's too bad cause I really like .astro components!
• Ability to opt-in to SSR on a per-page basis

[davidhellmann]

Ability to opt-in to SSR on a per-page basis

That would be great. My +1 for this. it's a reason i look at NextJS at the moment :/

[zadeviggers]

My 4 big things:

• Hybrid generation (some pages rendered as static HTML, some as server-side functions). This is the feature I'm the most excited for.
  • It would also be cool if pages could be "static" but with the ability to stream(?) in something like a comments section Astro component that was rendered server-side, after the initial page load.
• Form handling. I think this could have a lot of use in mostly static, content-focused sites, for things like feedback forms (I know you can already use Netlify forms for this use case, but a form handling system would be helpful across hosts and be more flexible) and comments sections.
• Incremental static regeneration Incremental builds (I got the two terms confused. Sorry!) This is useful for large sites with lots of content with high build times. With incremental builds, a change made to a single page in a CMS could show up on the live site much faster.
• Better support for vanilla javascript in <script> tags. Currently, it's a colossal pain to pass variables into script tags without losing all of the Vite goodness like npm packages. It also seems weird that the client: directives are supported on framework components but not on Astro components with script tags, which means that users are encouraged to load an enormous, often very overkill, UI framework, just to have the ability to use some of Astro's basic features, which seems to go against the whole "ship less JavaScript" philosophy that Astro is built upon.

Also, the ability to export functions from Astro components would be cool.

[kaushalyap]

I would recommend incremental builds over ISR. In ISR you delay building least frequently accessed pages, in incremental builds you only build what is changed.

With ISR a change made to a single page in a CMS could show up on the live site a lot faster.

I wonder how Astro would know content changes in CMS, AFAIK there is no data layer in Astro like Gatsby.

[AndreaPontrandolfo]

@zadeviggers

• Better support for vanilla javascript in <script> tags. Currently, it's a colossal pain to pass variables into script tags without losing all of the Vite goodness like npm packages. It also seems weird that the client: directives are supported on framework components but not on Astro components with script tags, which means that users are encouraged to load an enormous, often very overkill, UI framework, just to have the ability to use some of Astro's basic features, which seems to go against the whole "ship less JavaScript" philosophy that Astro is built upon.

If you need this kind of dinamicity and "state control", chances are that you really need a UI framework (be it React, Svelte, etc...). Astro is not meant to replace them, it is meant to integrate them as needed.

Also, the ability to export functions from Astro components would be cool.

What would be the use-case for this? If you need a reusable function just define it in src/utils. Exporting utility functions from Astro components would be an anti-pattern, i think.

[lloydjatkinson]

Unit testing support

Not only for Astro but also ensure that testing still works correctly for client side framework components by making sure existing standard tooling integrates. For example, I currently have a site with Astro and Preact components. When using Vitest and Testing Library, the tests fail because React isn't installed - I believe this is because the Vite in Astro and Vite in Vitest are not integrated so Vitest has no idea it should try looking for Preact instead. Right now this is causing a problem.

• Support Vitest and integrate it with Astro's Vite
• Ensure client framework testing works
• Implement https://testing-library.com/ support for Astro

Allow developers to mock Astro.glob() inside unit tests

There is currently no way of mocking the glob function meaning that we have to rely on real files being accessed during unit tests. This makes testing coupled to file layout and is generally hard to test. It would be great if we could mock glob so that we can pass in test data. Even if most Astro components, for example, use only props - there's still going to be some root component that accesses the markdown files.

Linting and formatting support

I believe there is a prettier plugin and a WIP ESlint plugin for Astro - it would be great to have linting and formatting support available.

Stack traces and error messages

Sometimes it's impossible to find which file caused the build to fail or which line in a file.

“failed to load module for ssr: <file>”

This could do with giving more context, why did it fail? What error caused it?

[Tc-001]

Small bias, but server-side islands.
I think that would really be a useful thing that sets astro apart and provides quite a lot of flexibility for developers in what they can render without needing client-side JS

(Also it fulfills the per-page SSR so many have requested here and I think does it even better with more control)

[CanRau]

Curious as to what exactly your referring to 😇

[Tc-001]

#116
(The maintainers already know about it, but now that v1 is out I think it can be brought up again)

[okikio]

• Astro needs a partial spec., detailing how it will handle Astro Syntax, Tokenization and Typescript support (specifically the Astro XML Spec will be a slight fork of the XML5 Spec with small tweaks that allow Astro to be well, Astro. IMO, we'll make the spec very lax to avoid unforseen bugs, the spec will mostlikely be a living document. We may even need to spec out Typescript for this to work properly, and for those who think this isn't neccessary, I assure you it is, right now Astro has a bunch of phantom bugs who's origin aren't clear, a good spec would simplify this process).
• Astro needs an AST to make it easier for integration devs to craft amazing integrations
• Astro needs a chart documenting the exact way Astro works in the background, and how Vite plays a role, this will allow for a better understanding of Astro, and help newcomers get comfortable with the codebase
• The Astro vscode extension needs to use the compiler on the backend to ensure matching behaviour with said compiler, the extensions current use of Regex is not sustainable.
• SSR and Build Mode unification. The results of Build and SSR mode can vastly differ, we need to tighten up this behaviour (I would attribute some of this behaviour difference to Vite, but we still need to tighen this up).
• Make Astro portable, as in let Astro run on Deno, Bun, Browser, The Next Big JS Runtime, etc...

^ These would be great to have for v2.0, but I'm thinking we'll only be able to get a small Astro Tokenization Spec. out, document how Astro works on the backend (with charts), a small AST preferably acornjs based, and SSR/Build Mode Unification. The will probs have to be left for v3.0

[Princesseuh]

Just for context, the language server using the compiler is planned to happen in the coming weeks, it was originally even supposed to happen pre-1.0, about a month or two ago. The PR on the language server side is ready to go, but is currently blocked by bugs in the compiler

Also, it might not be exactly what you're thinking about in this post, but the compiler can already output an AST - it currently powers the Prettier and ESLint plugins 😄

[dselles]

I see Astro's leaning into this content-first approach and showcasing blogs as a key use case, which I really love. However, in practice, as a relatively novice programmer, at present it's really, really challenging figuring out how to implement standard blog features like categories and tags. While I know this is currently technically possible, and that there's a lot of customization here, I wonder if there could be a Blog-Tools extension (or something similar) which would enable file-based routing for categories (e.g. inside a blog folder in src, there could be a travel folder, a recipes folder, etc.) and blog posts in those folders would automatically have those categories attached. I'm thinking something along the lines of how Hugo does Sections, which provides some really handy tools for categorizing content and creating filtered links.

That said, having some really well-crafted tutorials which showcase how to approach this within Astro's current capabilities might do the trick, too, as @Olyno suggested above. I can't stress enough how critical a thoughtful tutorial ecosystem is to the long-term success of a platform... I've been watching every recorded livestream you all have been doing and they've been helpful, but I've really been missing the lack of in-depth tutorials to help be unlock everything Astro is capable of (for one example - injected frontmatter sounds amazing, and after looking through all the resources I've been able to find, I still don't really understand how it works or how to do it. This is how I've been feeling with a lot of new features Astro's been rolling out as of late).

[tanepiper]

Some of the things have been mentioned here already, but for us:

• Functions as Props and page-level SSR (already commented here [Planning] What should we work on next? #247 (reply in thread)) - similarly being able to mix and match Astro components with other frameworks, or be able to nest framework components inside Astro to make page building easier. We also find ourselves not working in the Astro context much.

• Incremental building - we have a source of data that will generate around 500k pages, we don't want to rebuild that every time there is a small change - currently we're looking into a solution to replace Globs with querying a database that allows us to mark when items were built and detect changes, this would then only pass those pages to getStaticPaths - but currently with asset hashing this can cause other issues

• Two RFCS - RFC for Astro.extend User/Plugin Space #210 and RFC: Astro.context #230 - if these could progress in some way, they are related a little bit to each other in the ability to extend Astro without building a whole integration. Both would need to work in both SSG and SSR

[kaushalyap]

+1 for incremental builds

[jtag05]

Something along the lines of #230 would be incredibly useful. Not being able to share state securely in a request context is a major drawback for me at the moment. The only current solutions would be to defer user specific requests to the client or forego any "client-side" caching of data fetched during SSR. Using nanostores does not guard against cross contamination if multiple requests are handled in parallel.

[CanRau]

Red John is it you? 👀

[mitchellworks]

+1000 incremental builds :)

[Steve-Fenton]

+1 for incremental builds from here, too!

[budparr]

I think improving build time performance on an absolute basis to get it closer to 11ty, etc. would be great and a big differentiator for those of us coming from a Hugo/11ty world.

[unbiased-dev]

I personally would like to see (and I'm aware some of these were already mentioned, I'm repeating them for visibility):

• A client side router, turbolinks and swup were there for a time before they all got borked. I'd feel safer with an inhouse solution for this. This should also support/work with the current framework integrations or in other words, play nice with rerunning scripts on navigations.
• Opt out of SSR for certain routes, so that we can prerender some static pages that have no point of being rerendered on every request.
• Incremental builds, this plays nice with the prerendering bit.
• Any form of form handling, pun somewhat intended, the current killer feature of the "compact disk" framework is how easy and fast it is to write forms without hooking up client side JS left and right. This also fits in the "0 js shipped" ethos. Just make sure to put proper acknowledgment so they don't tweet at you tweet less :)

[edit]
Additionally, I see one of the most popular request is MDX related. While I appreciate the work being put into having MDX files as pages and out-of-the-box support for code highlighting etcetera, I don't think MDX is the right focus. Mainly because most MDX integrations you (the core team) can write is something I can write myself as it's really a user-land issue/feature (or at least it should be through some way of hooking into the mdx resolver step). The points above (router, opt out ssr incremental builds, form handling) are real framework-land features which are harder for me to hand roll (if not impossible without deep knowledge around astros core).

Of course I'm quite biased but that's how I see it as an outsider.

[tobiasschmidt89]

• Create or document a way to manipulate all md/mdx images with the astro/image integration (e.g. in the mdx example repository there is an example that uses the "MDX components export" to overwrite the h1 tag with a Title.astro component. I want to be able to do this in a layout or global config for all md/mdx images).
• Provide official integrations for typical SEO tasks (OG, Twitter cards, JSON+LD for Google Rich Results). E.g. an integration could have one component per Google Rich Results Schema with automatic fields validation. As Astro focuses on websites/content instead of webapp functionality SEO can be a crucial decision criteria to select a SSG.
• Check if Astro can be moved from node to deno (deno is more forward thinking when it comes to frontend/backend compatibility - e.g. global fetch API is available for free; also deno avoids node_modules folder which helps in storing website code in e.g. Dropbox). I like Astro, but it feels like a huge step back using node again after using deno for most of my work for some months.
• Move all unnecessary features into an integration plug-in to make Astro core as slim as possible (saves time, energy and money for CI in case e.g. md features are not needed in case only Storyblok CMS content is used).
• At the moment <script> and <style> Tags are processed automatically. This was a bit confusing when I started. I would enable this behaviour with an attribute instead to make components less magical (e.g. is:processed attribute).
• Incremental builds, canching, ..., and everything that makes builds fast and CI cheap.

Thanks for developing Astro.

[AndreaPontrandolfo]

• A client side router, turbolinks and swup were there for a time before they all got borked. I'd feel safer with an inhouse solution for this. This should also support/work with the current framework integrations or in other words, play nice with rerunning scripts on navigations.

+1 on this. It should also come by default with support for full-page transitions and links prefetch.

[wassfila]

regarding "Opt out of SSR for certain routes" and "Incremental Build" both could be solved with a rerender condition function, that way it could always return false to keep static, and then could be user specific as of number or requests count, time, or files modif compare, so many use cases are project specific, yet the conditional logic is the same rerender or not rerender.

[vxncetxn]

Q: What do you think should be worked on next?

• Per-page SSR, as has been mentioned multiple times in this thread.
• Unit testing via Vitest

Q: A confusing feature? / Q: A missing feature?

• PWA support via vite-plugin-pwa, this might already be supported but I can't get the with-vite-plugin-pwa example to work. I see on Discord that others are facing similar issues as well.

[AndreaPontrandolfo]

• PWA support via vite-plugin-pwa, this might already be supported but I can't get the with-vite-plugin-pwa example to work. I see on Discord that others are facing similar issues as well.

+1. I used vite-plugin-pwa in my astro project and it was a bad time. It kind of worked, but i faced a lot hurdles. A direct Astro integration (essentially a Astro wrapper for vite-plugin-pwa) would be great!

[kgeis]

• better out-of-the-box support for legacy non-ESM JavaScript
• HTML validation as part of build; right now, I need to open each of 40+ files in my (smallest) site in VSCode separately in order to see validation errors
• specific support and/or documentation for monorepos containing multiple sites with common components, layouts, and even pages (e.g. 404.astro).

[JLarky]

I would say that Astro should focus on a use case that was presented in the Flamethrower.js video.

• Improve CMS capabilities (cli/pluggable themes/integrations with headless CMS and wordpress)
• improve SPA story (astro-spa, integrations with tubro, flamethrower)

What I personally want to see more of is:

• HMR
• and improve progressive enhancement story around forms (I know that some work already started on Form component)

[nathanchase]

Auto-Import components from /components folder - #258

[crutchcorn]

I deeply appreciate the enthusiasm and wanting to move forward and experiment within this thread! :D

That said, I think some of these ideas tend to be pretty heavy lifts that can change what I think are some of the inherent strengths Asto has today with MPA SSG building.

These are the things that are preventing me from completing my blog's migration to Astro:

Testing Support

I know that there's actively work being done within this space, but the ability to do integration-style testing (I was thinking of Testing Library, since much of the work can be re-used) APIs on .astro components would be immensely helpful in verifying a lack of breaking changes in our markup.

Localization

Currently, if you want to setup routes such as:

'/posts/test' # English
'/en/posts/test'

You have to eject from page-based routing, which makes maintainability support challenging.

Ideally, I would love to see a route like:

/[locale]/posts/[postid]

And return:

params: {
  postid: slug,
  locale: locale === 'en' ? '' : locale
},

But returning an empty string isn't supported.

I know there's one issue similar to this:

withastro/astro#3990

But this issue was closed before resolution of this issue.

Images

I know that images are marked unstable currently, but there are a number of issues I've ran into while trying to use @astrojs/image outside of Vite. The main reason I want support for this is so that I can use the package within astro.config.js within a remark plugin so I can replace all markdown (not MDX) images with a resized image.

Currently, it seems like the blocker is that images must be inside of src or public, per a comment that @FredKSchott made recently.

[davidhellmann]

I'm also interested in the Localization thing.
currently I have:

pages
- [locale]
- - [...uri].astro
- [...uri].astro

to handle this. would be great to have just one file

[Alexandre-Fernandez]

I'm working on a library to handle this and more, in the meantime I did make a PR in https://github.com/yassinedoghri/astro-i18next that handles this, it's merged in the dev branch at the moment.

[mitchellworks]

Please, incremental builds. We need to be able to publish a post in the CMS and trigger just that page to build and deploy to S3 (with Cloudfront invalidation).

[FredKSchott]

Update: Thanks everyone for leaving feedback! I've read every comment left so far, and I've summarized the top 10 requests that I've seen here into a poll in our Discord #vote channel to help rank them by interest. The Astro Maintainers and Core team will use this to help inform our post v1.0 roadmap over the next week or so, with a goal of publishing a public roadmap once it's ready.

If you have a second, please vote! (#vote channel in sidebar)

[nickmccurdy]

Can this be marked as the answer (or otherwise pinned) to make it easier to find?

[delucis]

Neither of those seem to be available in discussion threads like this — I've copied this update into the original post to make it easier to find!

[ShivamJoker]

It would be great to get the ISR supported at least the on demand regenration

[Alexandre-Fernandez]

make injectScript from the config:setup hook take another argument to specify which page/route to inject the script in ("*" by default)

[matthewp]

Closing as this is an old issue, please create new ones for your ideas.