Planning Astro 6.0 #1174
Replies: 40 comments 81 replies
-
|
Beta Was this translation helpful? Give feedback.
-
Since it is a breaking change anyway we could consider exposing the v4 API by taking in Standard Schema. This way people using zod provided by us can continue to do so but we enable people to use any validator they want (as long as it is compatible), which has been asked multiple times. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah I think the current state of the standars schema spec does not allow us to adopt it. I'll bring it up on their repo |
Beta Was this translation helpful? Give feedback.
-
|
Would it be an option for Astro to support selected schema libraries via Standard Schema (you can check the vendor via |
Beta Was this translation helpful? Give feedback.
-
|
Yes it would be possible but I don't know if we want to take on the maintenance of this kind of thing. Sure there are solutions like https://github.com/standard-community/standard-json/ but since json schemas have been requested as part of the spec already, I thought we could just wait more until it is adopted. I don't think we are in a hurry to make Astro support Standard Schema btw so if that doesn't go in the major, then maybe in the next one! |
Beta Was this translation helpful? Give feedback.
-
|
If there is anything I can do to help Astro support Valibot, besides the Standard Schema change because I can't decide that on my own, please let me know. |
Beta Was this translation helpful? Give feedback.
-
|
For people wanting to follow: looks like form data handling won't be part of standard schema: standard-schema/standard-schema#95 (comment). So we'll have to think about it |
Beta Was this translation helpful? Give feedback.
-
|
Rolldown support would be really nice. It would be nice to finally deprecate implicit head behavior (this is where you can omit the |
Beta Was this translation helpful? Give feedback.
-
|
Remove node 18 support |
Beta Was this translation helpful? Give feedback.
-
|
Breaking change: stop exporting our zod dependency to users, and let users use their own version. Having users depending on our version comes with a lot of strings attached. Among them, the difficulty to upgrade zod as we want. |
Beta Was this translation helpful? Give feedback.
-
What were the reasons for this conclusions? |
Beta Was this translation helpful? Give feedback.
-
|
Like Matt said because we use it internally anyways |
Beta Was this translation helpful? Give feedback.
-
|
It seems we're going around in a circle. That's the reason for my proposal. Is there some other reason I'm missing? The whole reason for my proposal is since we use it internally, exposing it to users makes our maintenance difficult; we can't upgrade it without doing a major. |
Beta Was this translation helpful? Give feedback.
-
|
mmmh I see. I guess we'll have to talk about it again for the next standup |
Beta Was this translation helpful? Give feedback.
-
I had issues with zod within a monorepo setup recently. So for example, if I have two packages @repo/astro and @repo/schema, having a version not exactly matching the one that Astro uses internally created problems.
I haven't had much time to look deeply into the issue, but in my modest opinion it would be best to let users install zod on their own when they need it. |
Beta Was this translation helpful? Give feedback.
-
|
Breaking change: use Internally, we use |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Unsure if this is planned, but one breaking change would be to make |
Beta Was this translation helpful? Give feedback.
-
|
Yes, definitely. That was a fix for incorrect behaviour that we needed to put behind a flag as people could be relying on it. We may want to add a |
Beta Was this translation helpful? Give feedback.
-
|
Check todos in the codebase to see if some things could be cleaned up |
Beta Was this translation helpful? Give feedback.
-
|
In case Rolldown support lands in Vite 7, taking another look at CSP in dev mode might be interesting! |
Beta Was this translation helpful? Give feedback.
-
|
I wonder if we should disallow using
What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
I think it's better to deprecate its use rather than removing it immediately. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah that's what I meant. I guess my question is just: do people agree with this? |
Beta Was this translation helpful? Give feedback.
-
|
I think so. We'd be removing |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Deprecate config values not provided by |
Beta Was this translation helpful? Give feedback.
-
|
But what's blocking from using |
Beta Was this translation helpful? Give feedback.
-
|
Ecosystem compatibility. With a small number of variables defined, such as
It doesn’t matter if the code runs on the server or the client or in a webworker, in Astro or Vite, or even somewhere else. So long as those variable are defined, there’s always a way to reference the assets you need. It’s common to have a landing page, marketing site, or blog written in Astro, with an admin dashboard written in React in Vite. This compatibility means I can easily share these components across projects. It’s a lot easier to check if Setting Keeping these
Many, many frameworks use the pattern of setting environment variables and using a prefix when it should be a public environment variable. I plan to continue to use that env pattern in Astro so long as it’s supported. I don’t mind if these variables are also supported in Please, don’t break |
Beta Was this translation helpful? Give feedback.
-
|
There may be a misunderstanding. The intention is to deprecate properties that belong to Astro, not Astro and For example we don't want (and probably can't) remove all these built-ins: https://vite.dev/guide/env-and-mode.html#built-in-constants However, |
Beta Was this translation helpful? Give feedback.
-
|
ASSETS_PREFIX is an Astro field, but is used in components outside of Astro. ASSETS_PREFIX is one of the required puzzle pieces to build a url, and without it, either referencing an asset with only I currently use my react, astro, and mdx components across multiple projects and frameworks, and I want to continue to do that. I think compatibility is more important than moving ASSETS_PREFIX somewhere else, where it’s harder to use. I don’t mind if the property is duplicated or stays where it is. |
Beta Was this translation helpful? Give feedback.
-
Can you please show an example? And can you explain why you do so? How do you document the use of this "probable" variable to your fellow maintainers?
Sorry if I seem dumb, but I still don't understand what kind of compatibility you're talking about. In my head I'm picturing this variable used everywhere, even in contexts where it doesn't exist. Is that what you're talking about? The fact that "you can use", even though it doesn't exist? |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
|
FYI this is not flat routing, this is route grouping. You can build custom abstractions in userland already with https://inox-tools.fryuni.dev/custom-routing |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! I’ve solved. Fryuni/inox-tools#224 |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
|
It may make its way to core one day! But that can happen in a minor since it doesn't contain breaking changes |
Beta Was this translation helpful? Give feedback.
-
|
Feel free to upvote #1026 |
Beta Was this translation helpful? Give feedback.
-
|
GitHub-style admonitions. Would be great to keep your content portable |
Beta Was this translation helpful? Give feedback.
-
|
Hi, it has been requested in #860 already. FYI I think there's a rehype plugin somewhere that allows to do this, so no change in core is needed most likely EDIT: there's https://starlight-github-alerts.netlify.app/ for Starlight |
Beta Was this translation helpful? Give feedback.
-
|
Is there a reason templates have to use Astro templating language? Can we let people write their own template integrations like Vue templates or other formats to plug into Astro? |
Beta Was this translation helpful? Give feedback.
-
|
Astro has integrations for frontend frameworks I mean do Astro templates have to use Astro templating language for core components including SSG and SSR? |
Beta Was this translation helpful? Give feedback.
-
|
Full pages just in React or Vue, for example? |
Beta Was this translation helpful? Give feedback.
-
|
@louisescher Yes Astro could support pluggable backend templates. Vue templates are more powerful than Astro templates like scoped slot properties and they have better tooling. Lot of good feature suggestions for Astro LSP and tools are closed because Astro team can't do it. |
Beta Was this translation helpful? Give feedback.
-
|
We indeed have limited capacity so we have to prioritize. For what you're asking, it's a bit late: Astro 6 will soon be in beta and we haven't planned to add any big major feature before stabilization. However, there's a roadmap discussion for what you're asking so I encourage you to check it out and chime in: #1230. |
Beta Was this translation helpful? Give feedback.
-
|
Also, quick note re: “Lot of good feature suggestions for Astro LSP and tools are closed because Astro team can't do it.” — I’m not aware of these. Please do create discussions and share ideas for LSP improvements! |
Beta Was this translation helpful? Give feedback.
-
|
One source of confusion that would be nice to improve is For example, One idea was having an option called Previous discussions:
I prefer having |
Beta Was this translation helpful? Give feedback.
-
|
Hi! Yes it's planned for v6, we have a todo for it in the codebase: https://github.com/withastro/astro/blob/b03ce8ab36df7fbced4ff60f06dc9ecce2431b05/packages/astro/src/core/routing/manifest/create.ts#L258. Thanks for the reminder! |
Beta Was this translation helpful? Give feedback.
-
|
Another small fix, but possibly breaking change, would be never upscaling images with the image service. The current behavior is unexpected withastro/astro#13186 (comment) and the exception/old behavior doesn’t match the documentation:
Manual filtering of image sizes adds friction and is error prone. I just don’t see a use case for upscaling images. If a user wants to upscale an image, they should use an AI upscaler. If it’s pixel art, they should use css image-rendering. Otherwise, it’s just shipping a lower-quality image while using more bandwidth. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I agree. We do already do that when generating a srcset for responsive images, but I agree we should enforce this in the default service too. |
Beta Was this translation helpful? Give feedback.
-
|
I've created withastro/astro#14465 |
Beta Was this translation helpful? Give feedback.
-
|
Respect
Astro uses the function internally https://github.com/withastro/astro/blob/667bd64a28ca26bbbc50d17abf0b137f803e450d/packages/astro/src/core/create-vite.ts#L243 , so I’m unsure why this option can’t be set via the config, vite plugins, or astro plugins. I don’t see any alternatives that offer the same flexibility as It’s a major blocker for me. If I could make only one change, this would be it. I would love to hear of workarounds if there are any. |
Beta Was this translation helpful? Give feedback.
-
|
Does that need to be a major? If we allow it via an option but we keep the current behavior by default, that could go in a minor |
Beta Was this translation helpful? Give feedback.
-
|
I would love to see it go in a minor version as a new feature or a bug fix! That’d let me start prototyping a project that depends on |
Beta Was this translation helpful? Give feedback.
-
|
Then you should create another discussion for it so we don't forget about it! I'd love to read more about your use case and how you would use it |
Beta Was this translation helpful? Give feedback.
-
|
Great! I created a bug report and reproduction. My prototype depends on the third use-case, and will likely be in the form of a plugin like Starlight. I have over 12,000 words of notes on the topic, but I’ll save that write-up for another night. Thanks again for your help! I really appreciate it. |
Beta Was this translation helpful? Give feedback.
-
|
Proposal: framework-first islands that “just work” across nested trees. The idea is to:
This directly addresses:
Full Discussion: Framework-first islands (streaming SSR, shared Context & Hydration) (1239) |
Beta Was this translation helpful? Give feedback.
-
|
For the SSR/Streaming/Hydration related features it seems even more feasible now that it was announced "vitejs/plugin-rsc" (package, docs) as it claims to be Framework-agnostic and is built on top of vite environment API. |
Beta Was this translation helpful? Give feedback.
-
|
React compiler is nice to have. It is live and we can use it under some parameter flag in the react integration. |
Beta Was this translation helpful? Give feedback.
-
|
This has been proposed before and doesn't need to wait for Astro 6, feel free to send a PR! #1156 |
Beta Was this translation helpful? Give feedback.
-
|
I would wish for singleton support, as I need this for CMS based websites :) |
Beta Was this translation helpful? Give feedback.
-
|
Hi this probably could be done in a non breaking way so we don't need to couple it with v6! |
Beta Was this translation helpful? Give feedback.
-
|
I think it might already be planned, but support for the Cloudflare Vite plugin or more integrated Cloudflare Workers development with custom entry points would be awesome! |
Beta Was this translation helpful? Give feedback.
-
|
Yes we are working on it currently! |
Beta Was this translation helpful? Give feedback.
-
|
vite v8 and full bun support |
Beta Was this translation helpful? Give feedback.
-
|
We won't wait for Vite 8 to release but we hope to support it in a v6 minor alongside Vite 7. No way to know just yet. About Bun (runtime), this is still not planned. Bun aims to be compatible with Node so any bug specific to using Astro with Bun should be reported to the Bun team. |
Beta Was this translation helpful? Give feedback.
-
|
I propose adding built-in support for i18n based on file suffixes: e.g. Another ask would be more robust handling of errors in pages - e.g. sometimes Astro build crashes when unavailable image URL occurs in some markdown file. Ideally, the build should just produce a list of offending markdowns, but still go on and process these pages (e.g. maybe replace the unloaded image with some placeholder) And allowing custom location for |
Beta Was this translation helpful? Give feedback.
-
|
All these things could happen in minors so feel free to open new proposals for these ideas if none exist! |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if you want the file suffixes for the pages or content. If you wish to have it for content I've built custom loaders allowing this and more related to i18n: https://github.com/openscript/astro-i18n/tree/main/libs/astro-loader-i18n |
Beta Was this translation helpful? Give feedback.
-
|
@florian-lefebvre What is the appropriate forum for submitting ideas/feature request in more preliminary form for discussion (so, not as well-designed/well-thought as RFC)? Even in this Discussion board, there is no category for "Ideas" or "General" :( E.g. I'd like to propose to add conditional rendering in the attribute-style of vuejs, as |
Beta Was this translation helpful? Give feedback.
-
|
A discussion on this repo is the right thing to do! Check the readme "stage 1 proposal" section to learn more |
Beta Was this translation helpful? Give feedback.
-
|
ISR through Content Collections |
Beta Was this translation helpful? Give feedback.
-
|
Those 2 things are pretty different, you may be interested in route caching: #1245. It can occur in a minor |
Beta Was this translation helpful? Give feedback.
-
|
I might've posed it wrong, but isn't Content Collections the perfect place for Astro to only SSG 1 new page as opposed to rebuilding all of them? Maybe I'm missing something. I'm using Astro for building customer websites, so only rebuilding the new/updated ones is perfect for me. Now I'm using Vercel for that reason only. Do I make sense? |
Beta Was this translation helpful? Give feedback.
-
|
That's called incremental builds in this case, ISR is more a runtime thing. But yeah this has been requested before, I'm not sure if there's a dedicated discussion for it yet (if not, feel free to create one!). In any case, this probably could be done in a non breaking way so we don't need to couple it with Astro 6. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks everyone for all of your feedback, it has been super valuable! As we're approaching stabilization, I'm going to close and lock this discussion. If you have any feedback about v6, there is a thread on Discord: https://discord.com/channels/830184174198718474/1449132280432951398. |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Important
This is not final. It only helps use knowing what to prioritize/aim for.
Let's start talking about what we want to tackle in Astro v6 (stabilizations, deprecations, removals, breaking changes...)! Here is what I'd like to see tackled:
@astrojs/vite-plugin-fontspackage)>=3.25.0to support v3 and v4. Will require types constraints updatesPlease share what you'd realistically want!
Beta Was this translation helpful? Give feedback.
All reactions