cli VS zod

You'll need to install the Supabase CLI in different ways depending on your OS, check out this guide for details and come right back here.

Recently, I noticed that in our remote project, the database storage schema has a migration not present when one sets up the local stack for development. Upon inspection, the Supabase CLI uses an old version of the storage image. Currently, there is no way to change this (that I know of) until the CLI team updates the CLI to use this version.

@doganugurlu Looks like Deno team implemented a fix https://denostatus.com/cllm0jzq219036bjottk03k2ac Are you still experiencing the issue?

We used to cache the modules locally, I will need to check if we made any configuration change. Can you kindly open an issue for Supabase CLI - https://github.com/supabase/cli/issues

> Oh, I had no idea that the functions routes were "wild card"! I don't think that's mentioned anywhere in the documentation, btw.

Good point! will update the docs.

> Sorry, I actually mean "import-maps": https://github.com/supabase/cli/issues/1338

I'll take a look at this issue. We've improved import map resolution in the last couple of CLI releases. But it looks like there are more edge cases.

We’ve moved the Supabase CLI to a fortnightly stable-release cycle. Every 2 weeks, we will update the latest tag on npm, the supabase/tap for homebrew, and the supabase scoop bucket. You can find the binary downloads in our GitHub latest release.

I think we've been working on that recently here: https://github.com/supabase/cli/pull/907

Can you try it locally with the supabase CLI? https://github.com/supabase/cli

For more info see this issue on GitHub.

I opened a Github issue: https://github.com/supabase/cli/issues/939, but I figured I'd see if any of you hit this and, hopefully, got past it.

Are there plans to support connections to self hosted remotes (to deploy to self-hosted instances, for example) with the cli? https://github.com/supabase/cli/issues/753

Zod is a TypeScript-first schema declaration and validation library. It helps create schemas for any data type and is very developer-friendly. Zod has the functional approach of "parse, don't validate." It supports coercion in all primitive types.

Link: https://zod.dev/

You can check out their documentation here.

You can learn more about Zod on their website here.

In JS, it's a good idea anyway to use some JSON parsing library instead of JSON.parse.

With Zod, you can use z.bigint() parser. If you take the "parse any JSON" snippet https://zod.dev/?id=json-type and change z.number() to z.bigint(), it should do what you are looking for.

We will validate our input using client-side zod. Zod handles TypeScript-first schema validation with static type inference. This means that it will not only validate your fields, it will also set types on validated fields.

A word of warning: while discriminated unions are very powerful, there's an ongoing discussion on whether discriminated unions should be deprecated and replaced with a different API.

I was first introduced to Zod by Adam Bobrow - a colleague of mine and a dear friend. Adam was sick and tired from JavaScript's brittleness, and about two years ago he started migrating our code base to TypeScript. But that wasn't enough for him. He kept complaining: "What good are my types, if some other service decides to send me bad data and breaks my code?". That's when he discovered Zod.

It is (or should be) common practice to parse/validate any external data you depend on. You should be doing this for Javascript too. I find that the library https://zod.dev/ is quite helpful for this

Astro uses Zod, a Typescript-first schema validation library, to type-check the collections' schemas. It helps validate data types when using collections inside UI components.