🐛 BUG: Astro check silently exists and doesn't report type errors when there are collection schema validation errors

[angelikatyborska]

Describe the Bug

astro check does not finish running and exits silently without reporting any errors when the following conditions are met:

• I'm using defineCollection with a schema
• I have a file in my collection that has a frontmatter that doesn't confirm to the schema

I have experienced this when I was trying to add typescript to my blog and couldn't figure out why astro check refuses to do any type validations. I realized what's going on only after I ran astro sync and fixed collection schema validation errors errors.

I suspect that this bug might affect reporting not only typescript errors, but also other checks that Astro runs.

Steps to Reproduce

1. npm create astro@latest using the official blog template (or checkout https://github.com/angelikatyborska/astro-check-bug and skip to step 6)
2. Install @astro/check and typescript
3. Introduce a trivial TS error into one of the .astro files, e.g. const foo: string = 3; console.log(foo);
4. Run npm run astro check and observe that the TS error is reported:

   angelika in ~/Documents/code/magical-mars (main | ∙1)
   $ npm run astro check
   10.9.2
   
   > magical-mars@0.0.1 astro
   > astro check
   
   18:37:45 [content] Syncing content
   18:37:45 [content] Synced content
   18:37:45 [types] Generated 260ms
   18:37:45 [check] Getting diagnostics for Astro files in /Users/angelika/Documents/code/magical-mars...
   src/pages/index.astro:7:7 - error ts(2322): Type 'number' is not assignable to type 'string'.
   
   7 const foo: string = 3;
           ~~~
   
   Result (15 files): 
   - 1 error
   - 0 warnings
   - 0 hints
   

5. Introduce a trivial schema error to one of the blog posts, e.g. in first-post.md, settitle: 3 (it's supposed to be a string, not a number)
6. Run npm run astro check again and observe no errors of any kind reported, but the process does exit with status 1.

   angelika in ~/Documents/code/magical-mars (main | ∙1)
   $ npm run astro check
   10.9.2
   
   > magical-mars@0.0.1 astro
   > astro check
   
   18:42:04 [content] Syncing content
   
   angelika in ~/Documents/code/magical-mars (main | ✔)
   $ echo $?
   1
   

What I would expect to happen instead, is to see the same errors as I see when I run npm run astro sync:

angelika in ~/Documents/code/magical-mars (main | ✔)
$ npm run astro sync
10.9.2

> magical-mars@0.0.1 astro
> astro sync

18:43:49 [content] Syncing content
[InvalidContentEntryDataError] blog → first-post data does not match collection schema.
title: Expected type `"string"`, received `"number"`
  Hint:
    See https://docs.astro.build/en/guides/content-collections/ for more information on content schemas.
  Error reference:
    https://docs.astro.build/en/reference/errors/invalid-content-entry-data-error/
  Location:
    /Users/angelika/Documents/code/magical-mars/src/content/blog/first-post.md:0:0
  Stack trace:
    at getEntryDataAndImages (file:///Users/angelika/Documents/code/magical-mars/node_modules/astro/dist/content/utils.js:163:26)
    at async syncData (/Users/angelika/Documents/code/magical-mars/node_modules/astro/dist/content/loaders/glob.js:99:28)

Link to Minimal Reproducible Example

https://github.com/angelikatyborska/astro-check-bug

[Princesseuh]

astro check is purely a type checker, most notably a clone of tsc with the added support for Astro files. It (intentionally, at this time at least) does not check for schema errors. This could change!

Moving this to a discussion / feature request, since it's not a bug

[angelikatyborska]

Thank you for the fast answer!

astro check is purely a type checker, most notably a clone of tsc with the added support for Astro files.

Thank you for that explanation! I wasn't entirely sure. In that case, I take back my suggestion that it should also report collection schema errors.

However, I have to insist that the scenario I described is a bug.

As you say, astro checks purpose is to do type checks. There is a set of circumstances when it doesn't do any type checks even when it's correctly configured to do so. It doesn't produce any information to the user as to why the type checks didn't happen, it just silently exits. Wouldn't you say that's a bug?

I don't know how the tool works internally, but I saw in the documentation that many astro commands, under the hood, run astro sync before they proceed. It looks like in the scenario I described astro check exits silently while an error during astro sync happened. Could it instead print an error message, something like "Sync failed. Rerun astro sync for details"? Something like that would saved me a lot of time of re-rereading the documentation of how to setup typescript in Astro, trying to figure out why the typechecks in my projects don't work.

For some context, I've been using Astro for 3 months, uisng astro check daily, and I wasn't even aware that astro sync exists. I only became aware of its existence yesterday, while trying to debug this problem, when I tried to use a collection for the first time.

[Princesseuh]

Yes, I'm talking purely in the technical sense here, schema errors are not "type errors", it works a bit differently. Much like in a TypeScript project you still use Zod to validate runtime values, because the types are only at build time.

The implicit sync should actually report the schema error, I'm not sure why it doesn't. I'll investigate!

[Princesseuh]

Moving this to the main repo at the request of @florian-lefebvre to investigate the astro sync part

withastro/astro#12724