refactor(astro): put them to follow a pattern for errors

[jp-knj]

Changes

• refactor(astro): Replaced generic Error throws with AstroError #13759 (comment)
• Introduced two scoped error definitions in packages/astro/src/core/errors/errors-data.ts
  • FileGlobNotSupported – thrown when a glob pattern is passed to file() loader.
  • FileParserNotFound – thrown when no parser can be determined for the file extension.
    Both follow the project’s error‐data convention (name | title | message | hint | docs tags).
• Replaced generic Error throws with AstroError in
  packages/astro/src/content/loader/file.ts.
  • throw new AstroError(FileGlobNotSupported)
  • throw new AstroError({ …FileParserNotFound, message: FileParserNotFound.message(fileName) })
• Added a changeset (pnpm exec changeset) so these improvements surface in release notes.

Testing

• Ran the full test suite: pnpm test – no regressions.
• Manual Smoke Tests
  1. file('data/*.json') → displays File glob pattern not supported banner.
  2. file('data/example.xml') → displays File parser not found banner with doc link.

No new automated tests — behaviour is unchanged; only error wiring differs.

Docs

No public-API changes. Docs remain valid.

[changeset-bot]

🦋 Changeset detected

Latest commit: 5325406

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codspeed-hq]

CodSpeed Performance Report

Merging #13761 will not alter performance

_{Comparing jp-knj:replace-astro-error-2 (5325406) with main (9d49297)}

Summary

✅ 6 untouched benchmarks

[ematipico]

Thank you @jp-knj. The position of the errors is important in this file. You must place these errors after this line, and before the @kind heading comment :

astro/packages/astro/src/core/errors/errors-data.ts

Line 1367 in f8cec06

[jp-knj]

@ematipico
Thank you, modify the position of error definitions

[sarah11918]

Are these content collections errors? If so, they need to go in the Content Collections section which is around line 1566!

All the errors will show up in the order they are written, including under the appropriate heading section:

[sarah11918]

Just some quick initial comments here before editing for docs!

[jp-knj]

Are these content collections errors? If so, they need to go in the Content Collections section which is around line 1566!

All the errors will show up in the order they are written, including under the appropriate heading section:

is two errors Okay after L1557, before L1559?

[sarah11918]

Thanks for updating based on my original comments!

Note: these errors are still not quite in the correct location! 😄 In this spot, they are showing up just BEFORE the proper heading. They should go AFTER the Content Collections heading, and typically we put newer errors at the bottom. You can check the live version of docs if it's difficult to picture here: https://docs.astro.build/en/reference/error-reference/ Figure out which message you want to follow, and place your messages after that one (for example, the last content collections error currently is "Unsupported transform in content config" so you could place it directly after that one, before the next heading.

Otherwise, I've made some suggestions below based on the structure of our error messages, and also where I think it would be helpful to send people for help. (e.g. if they passed a glob pattern, they probably don't need to go see how to construct a glob pattern, but instead, they need to see how the loaders work and which one should be used with a glob pattern)

See if what I've suggested makes sense, and please correct as necessary!

[ematipico]

Thank you! We can merge it once @sarah11918 approves it :)

[jp-knj]

Thanks too!!

I learned all about:

• Both the file loader and the glob loader are part of Astro’s Content Collections API.
  So, any errors about them naturally occur while working with Content Collections.
• In the error reference, sections are organized to match how users think when troubleshooting.
  For example:
  “I got an error while setting up Content Collections → I should check the Content Collections section.”
  That’s why grouping these under Content Collection Errors makes sense.

Then, to summarize

• Feature grouping → because they are part of Content Collections.
• Documentation structure → to keep the generated docs consistent.
• Maintenance rule → to place new entries at the end of the section.

That’s why placing them under Content Collections is the best choice.

I fully got them!

[sarah11918]

Thank you for these helpful error messages, @jp-knj ! We are happy to have your contribution! 🎉