Tentative list of deprecations and breaking changes for Astro 3.0 #502
Replies: 6 comments 7 replies
-
|
Something to think / talk about. CSS ordering bugs continue to happen. We need to investigate if there's an architectural issue where we cannot ensure the exact same CSS order between dev and build. This would be because of code splitting. If it turns out we cannot fix this, then we need to reconsider where to use |
Beta Was this translation helpful? Give feedback.
-
|
CSS ordering has always been a pain, even in Sometimes one of the issues is caused by the order when importing components. Given the following example, and assuming that the components use // page1.js
import ComponentA from "componentA.js"
import ComponentB from "componentB.js"// page2.js
import ComponentB from "componentB.js"
import ComponentA from "componentA.js"This might result in a problem where we need to know which styles come first. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, this is exactly the sort of problem we need to see if we can solve. If we cannot then it would make sense to change back to using class names. |
Beta Was this translation helpful? Give feedback.
-
|
Asocciated Vite issue for a similar problem: vitejs/vite#3924 (comment) - this also affects me on a Vite + React project using CSS Modules: enabling code splitting triggers the ordering problem. Though I may be discussing a different problem, CSS + JS modules are a messy task. |
Beta Was this translation helpful? Give feedback.
-
|
Started a discussion on ways to fix this: #510 |
Beta Was this translation helpful? Give feedback.
-
Implicit head injectionAstro will inject our head content (links and scripts) into the head, even if your page never has an explicit head tag. This causes bugs, especially with the introduction of content collections and its head propagation. Knowing that all pages have an explicit We could create a |
Beta Was this translation helpful? Give feedback.
-
What's the reason for removing the TS dependency? |
Beta Was this translation helpful? Give feedback.
-
|
The idea would be to make it an optional peer deep. The idea is to make |
Beta Was this translation helpful? Give feedback.
-
|
I see. I come from a different background, where the language server is just a consumer of the API that checks for diagnostics. And - ideally - this API lives inside a "core" package, where the core is |
Beta Was this translation helpful? Give feedback.
-
|
Ah yes, this is different here because the "API that checks for diagnostics" is TypeScript, which Astro itself does not depend on. For the actual Astro-related diagnostics, the language-server does depend on a core package, the compiler. Having a non-dev dependency on TypeScript is generally unwanted, because you want users to be able to control the version. The version of it might even be provided by their editor, for instance |
Beta Was this translation helpful? Give feedback.
-
|
A feature we had in the Snowpack days but dropped in the switch to Vite was requiring the Reason: I've spent a bunch of time debugging very weird issues with folks only to realize that they had installed a package that used the |
Beta Was this translation helpful? Give feedback.
-
|
Endpoints have a legacy 2 argument form that we still have code for in the codebase. We can remove that in 3.0 |
Beta Was this translation helpful? Give feedback.
-
|
3.0 is out... |
Beta Was this translation helpful? Give feedback.
-
Body
As we're heading towards 3.0, @matthewp and I thought it would be neat to have a discussion / document talking about the plans regarding deprecations in Astro 3.0. Previously, we would've had this in private among us maintainers, but we figured there was no downsides to having this public. So here we are.
Core
Responses is better in all cases apart from one (SSG, files that need specific encoding) and supporting both is leading to user confusion, maintenance burden and bugs.astro checkto a separate package, or at least its TypeScript dependency, in order to significantly reduce the size of theastropackage and allow users more autonomy over the TypeScript version.Beta Was this translation helpful? Give feedback.
All reactions