You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/content/docs/en/guides/upgrade-to/v6.mdx
+131Lines changed: 131 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -161,6 +161,137 @@ The following features have now been entirely removed from the code base and can
161
161
162
162
Projects now containing these removed features will be unable to build, and there will no longer be any supporting documentation prompting you to remove these features.
In Astro 5.x, it was still possible to use [the original Content Collections API first introduced in Astro v2.0](https://astro.build/blog/introducing-content-collections/), either through a `legacy` configuration flag or via built-in backwards compatibility. These methods allowed you to upgrade to Astro v5 even if you were not yet ready or able to update your existing content collections to those powered by the new Content Layer API.
170
+
171
+
**Astro v6.0 removes this previously deprecated Content Collections API support entirely, including the `legacy.collections` flag.** All content collections must now use [the Content Layer API introduced in Astro v5.0](https://astro.build/blog/content-layer-deep-dive/) that powers all content collections. No backwards compatibility support is available.
172
+
173
+
#### What should I do?
174
+
175
+
If you had previously enabled the legacy flag, you must remove it.
176
+
177
+
```ts title="astro.config.mjs" del={5}
178
+
import { defineConfig } from'astro/config';
179
+
180
+
exportdefaultdefineConfig({
181
+
legacy: {
182
+
collections: true,
183
+
}
184
+
})
185
+
```
186
+
187
+
Additionally, if you did not upgrade your collections for Astro v5.0, ensure that your content collections are **fully updated** for the new API.
188
+
189
+
Astro v5.x included some automatic backwards compatibility to allow content collections to continue to work even if they had not been updated to use the new API. Therefore, your v5 collections may contain one or more legacy features that need updating to the newer API for v6, even if your project was previously error-free.
190
+
191
+
If you have [content collections errors](/en/reference/error-reference/#content-collection-errors) or warnings after upgrading to v6, use the following list to help you identify and upgrade any legacy features that may exist in your code.
Create `src/content.config.ts` and [define your collections](/en/guides/content-collections/#defining-collections) in it.
198
+
</details>
199
+
200
+
<details>
201
+
<summary>a configuration file located at `src/content/config.ts` / ([`LegacyContentConfigError`](/en/reference/errors/legacy-content-config-error/))</summary>
202
+
Rename and move this file to `src/content.config.ts`
203
+
</details>
204
+
205
+
<details>
206
+
<summary>a collection that does not define a `loader`/ ([`ContentCollectionMissingALoaderError`](/en/reference/errors/content-collection-missing-loader/))</summary>
207
+
208
+
Import [Astro's built-in `glob()` loader](/en/guides/content-collections/#built-in-loaders) and define the `pattern` and `base` for your collection entries:
209
+
210
+
```ts ins={3,6}
211
+
// src/content.config.ts
212
+
import { defineCollection, z } from 'astro:content';
<summary>a collection that defines a collection type (`type: 'content'` or `type: 'data'`) / ([`ContentCollectionInvalidTypeError`](/en/reference/errors/content-collection-invalid-type/))</summary>
229
+
There are no longer different types of collections. This must be deleted from your collection definition.
230
+
231
+
```ts del={7}
232
+
// src/content.config.ts
233
+
import {defineCollection, z} from 'astro:content';
234
+
import {glob} from 'astro/loaders';
235
+
236
+
const blog = defineCollection({
237
+
// For content layer you no longer define a `type`
<summary>legacy collection querying methods `getDataEntryById()` and `getEntryBySlug()` / ([`GetEntryDeprecationError`](/en/reference/errors/get-entry-deprecation-error/))</summary>
252
+
Replace both methods with [`getEntry()`](/en/reference/modules/astro-content/#getentry).
253
+
254
+
</details>
255
+
256
+
<details>
257
+
<summary>legacy collection querying and rendering methods that depend on a `slug` property / ([`ContentSchemaContainsSlugError`](/en/reference/errors/content-schema-contains-slug-error/))</summary>
258
+
Previously, the `id` was based on the filename, and there was a `slug` property that could be used in a URL. Now the [CollectionEntry](/en/reference/modules/astro-content/#collectionentry) `id` is a slug. If you need access to the filename (previously available as the `id`), use the `filePath` property. Replace instances of `slug` with `id`:
<ReadMore> See [the Astro v5 upgrade guide](/en/guides/upgrade-to/v5/#legacy-v20-content-collections-api) for previous guidance about backwards compatibility of legacy collections in Astro v5 and full step-by-step instructions for upgrading legacy collections to the new Content Layer API.</ReadMore>
Copy file name to clipboardExpand all lines: src/content/docs/en/reference/legacy-flags.mdx
+3-41Lines changed: 3 additions & 41 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,49 +3,11 @@ title: Legacy flags
3
3
i18nReady: true
4
4
---
5
5
6
+
importSincefrom'~/components/Since.astro'
7
+
6
8
To help some users migrate between versions of Astro, we occasionally introduce `legacy` flags.
7
9
8
10
These flags allow you to opt in to some deprecated or otherwise outdated behavior of Astro
9
11
in the latest version, so that you can continue to upgrade and take advantage of new Astro releases until you are able to fully update your project code.
10
12
11
-
importSincefrom'~/components/Since.astro'
12
-
13
-
## Collections
14
-
15
-
<p>
16
-
17
-
**Type:**`boolean`<br />
18
-
**Default:**`false`<br />
19
-
<Sincev="5.0.0" />
20
-
</p>
21
-
22
-
Enable legacy behavior for content collections (as used in Astro v2 through v4)
23
-
24
-
```js
25
-
// astro.config.mjs
26
-
import { defineConfig } from'astro/config';
27
-
exportdefaultdefineConfig({
28
-
legacy: {
29
-
collections:true
30
-
}
31
-
});
32
-
```
33
-
34
-
If enabled, `data` and `content` collections (only) are handled using the legacy content collections implementation. Collections with a `loader` (only) will continue to use the Content Layer API instead. Both kinds of collections may exist in the same project, each using their respective implementations.
35
-
36
-
The following limitations continue to exist:
37
-
38
-
- Any legacy (`type: 'content'` or `type: 'data'`) collections must continue to be located in the `src/content/` directory.
39
-
- These legacy collections will not be transformed to implicitly use the `glob()` loader, and will instead be handled by legacy code.
40
-
- Collections using the Content Layer API (with a `loader` defined) are forbidden in `src/content/`, but may exist anywhere else in your project.
41
-
42
-
When you are ready to remove this flag and migrate to the new Content Layer API for your legacy collections, you must define a collection for any directories in `src/content/` that you want to continue to use as a collection. It is sufficient to declare an empty collection, and Astro will implicitly generate an appropriate definition for your legacy collections:
43
-
44
-
```js
45
-
// src/content/config.ts
46
-
import { defineCollection, z } from'astro:content';
47
-
48
-
constblog=defineCollection({ })
49
-
50
-
exportconstcollections= { blog };
51
-
```
13
+
There are currently no legacy flags available. When new legacy flags become available, instructions for removing them and upgrading to the latest features of Astro will be listed below.
0 commit comments