Feature Request: Add a --watch flag to astro check

[ankushg]

Alternatively, add a --check flag to astro dev?

[matthewp]

Yeah, this seems reasonable. Going to address each of these ideas separately:

astro check --watch

We would need to add a filewatcher to this command. Is the use-case here that you would run astro check --watch in a separate tab? Or how would you expect to use this in practice?

astro dev --check

This one makes a lot of sense. Questions about what the expectation would be though:

1. Does this just check and print errors to the console?
2. Should an error show up in the browser even if it doesn't break the code?

The one downside to idea is that it locks us in to having this functionality remain in core, whereas with astro check --watch we could still move it down the line. But maybe we've already landed on keeping it in core anyways? Having the check flag in dev would make it much more useful.

[bholmesdev]

I'm personally +1 on astro dev --check. This falls in-line with our new astro sync command, which is run inside a watcher during dev to generate types. I also don't see a use case for just generating types without a dev server in a separate tab, so this would simplify local debugging.

[ankushg]

astro check --watch

We would need to add a filewatcher to this command. Is the use-case here that you would run astro check --watch in a separate tab? Or how would you expect to use this in practice?

I'm concurrently running astro dev, tsc --watch, eslint-watch and a filewatcher-wrapped astro check.

It would be "good enough" if the filewatching was included in astro check so I don't need to complicate my package.json, but astro dev --check would also make this redundant for my specific use case

astro dev --check

This one makes a lot of sense. Questions about what the expectation would be though:

1. Does this just check and print errors to the console?
2. Should an error show up in the browser even if it doesn't break the code?

I'd love for it to be configurable in some way. I can imagine messing around with styling with the goal of cleaning up the TS later and it would be annoying to have the error overlay pop up every hot-reload.

At the same time, I can also imagine clicking around on my site and wanting to be immediately alerted to any issues.

The one downside to idea is that it locks us in to having this functionality remain in core, whereas with astro check --watch we could still move it down the line. But maybe we've already landed on keeping it in core anyways? Having the check flag in dev would make it much more useful.

Yeah, this was the only reason I even suggested astro check --watch as an alternative to astro dev --check. For workflow purposes, astro dev --check seems to be the better experience

[matthewp]

What do other frameworks do here? Does SvelteKit or Next.js do typechecking in the dev server? And if so how do they treat errors?

[jasikpark]

I doubt that Next.js does typechecking in the dev server since they use SWC? which is ~ esbuild?

[bluwy]

astro check --watch sounds like a nice idea. astro dev --check could be a nice too as long as it doesn't block the dev server, but IIUC astro check runs on all files at once, the dev server doesn't give any benefit for it to run a single file at a time. For example, an integrated experience of eslint in Vite like https://github.com/nabla/vite-plugin-eslint is that eslint can run per-file.

Maybe it's not an issue, but it feels like it's only a sugar of astro dev & astro check --watch. astro sync during astro dev is different since it facilitates the authoring DX. astro check during dev doesn't necessarily improve the DX, you can run after making all the changes for example.

[bholmesdev]

These are all good points Blu. I hadn't considered that running via the dev server would mean checking files as you browse the site, when you probably want all files checked at once on startup. Leaning towards astro check --watch now!

[bluwy]

Re which files to watch, I checked svelte-check and it watches a simple glob of **/*.{svelte,d.ts,ts,js} 🙈

[Princesseuh]

This proposal has been moved to Stage 2, thank you everyone! #473