Planning Astro 6.0 #1174
Replies: 34 comments 68 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.
-
|
Enable Rather than a legacy flag for backwards compatibility, users can add a rehype plugin to preserve the old behaviour. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Is |
Beta Was this translation helpful? Give feedback.
-
|
Mmmh good point. It will keep working but there are going to be peer dependencies related issues. Not sure what we should do it, given that the code is not in the monorepo anymore IIRC |
Beta Was this translation helpful? Give feedback.
-
|
Hopefully not a breaking change, but it requires some exploration beforehand. Remove the use of Not sure if there's an alternative, but the use of this pattern was chosen because actions were initially created as an integration. |
Beta Was this translation helpful? Give feedback.
-
|
The proxy is only used on the client right? I think that's how trpc and others manage to get the types on the client without leaking any server stuff, so not sure we can avoid it |
Beta Was this translation helpful? Give feedback.
-
|
No, it's used to dynamically recurse the actions and rewrite the handlers, and inject a different scope. Check the file |
Beta Was this translation helpful? Give feedback.
-
|
Ah I see I think. I think we should keep the proxy for the client side impl, and maybe we can make another one for the server side impl since this is the only place where the context (and this) is used, if I read the code correctly |
Beta Was this translation helpful? Give feedback.
-
|
In most cases |
Beta Was this translation helpful? Give feedback.
-
|
I am quite excited to be able to use the Vite Environment API in Astro integrations. The execution order of the integration I currently maintain is brittle. I could see this removing a majority of the glue code. This is because different tools and adapters make assumptions of when code will run, where it exists (disk, virtual, etc.), what environment we are in. For example, in Qwik's Astro integration we need two separate processes in order to run the server and vite client build. Astro expects to always run the server build initially
Qwik expects the opposite. The client build is expected to run first, and pass this information over to the server build. It also expects certain code split files in the dist. This has always been difficult to reason about with Astro's adapters, and integration API, and has been a majority of our issues. There are some tricks that I've used to get it to work, such as injecting into the built files, virtual modules, finding some way to collect the information, but it always tends to lead to more issues filed and clever hacks. It seems with the environment api both could be done in the same process, and we could more easily coordinate how the application is built. Making Astro's integration ecosystem more stable. In particular I would like to be able to run Qwik's client build before Astro's server build. |
Beta Was this translation helpful? Give feedback.
-
Add optional path parameters like in SvelteKithttps://svelte.dev/docs/kit/advanced-routing#Optional-parameters Would be extremely useful for e.g. i18n if one would want not to have a prefix for the default locale (assuming that the pages' content is fetched from an API/translation store): Example i18n setup:
---
// src/pages/[[lang]]/some-page.astro
import { getYourTranslations } from "@/some/module"
const lang = Astro.params.lang || "en"; // let's assume that english is the default lang
const translations = getYourTranslations(lang); // for example, fetch your translations like this, could be done either way
---
<p>{translations.someText}</p>
What do you guys think? |
Beta Was this translation helpful? Give feedback.
-
|
This is already possible with the following pattern: |
Beta Was this translation helpful? Give feedback.
-
|
Yes, but unless you handle it properly on your own, this will catch routes like |
Beta Was this translation helpful? Give feedback.
-
|
Hey @Matb85, thanks for the idea. Would you mind creating a dedicated discussion for it? This thread is mostly for collecting existing discussions and it would a shame for this to get lost here. A dedicated post allows other people to upvote it, add feedback, etc. more easily. |
Beta Was this translation helpful? Give feedback.
-
|
Sure, done: #1220 |
Beta Was this translation helpful? Give feedback.
-
|
SVG's that are added with |
Beta Was this translation helpful? Give feedback.
-
|
Hey, thanks for the idea. Would you mind creating a dedicated discussion for it? This thread is mostly for collecting existing discussions and it would be a shame for this to get lost here. A dedicated post allows other people to upvote it, add feedback, etc. more easily. |
Beta Was this translation helpful? Give feedback.
-
|
Vite Environment API support! This would be really nice for easier Cloudflare workers integration, |
Beta Was this translation helpful? Give feedback.
-
|
This is planned and in progress already! |
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.
-
|
Hi, this is already possible! Here's some links to the docs for Vue, Svelte and React (all officially supported!): |
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.
-
|
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.
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