cli

@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 do have plans to improve the current database trigger behavior. Will share more updates on this in the coming months. Excited to hear more! Being able to trigger functions from DB & cron triggers without having to hardcode a secret (which causes them to end up in migrations files) will be a huge improvement. > Can you explain what do you mean by template URLs? Oh, I had no idea that the functions routes were "wild card"! I don't think that's mentioned anywhere in the documentation, btw. > Source maps, is it broken during local dev or when you deploy the function? Sorry, I actually mean "import-maps": https://github.com/supabase/cli/issues/1338 "Source maps" (does deno actually use source maps?) ARE broken as well. EG: The line numbers in runtime don't line up with the function code in the IDE or even that is in the docker volume.

Thank you for the helpful feedback. > Using supabase migration up would mean moving the latest migration out of the migrations folder, running supabase db reset, moving the file back in and then calling supabase migration up. We can definitely do a better job here. I'm adding support for db reset --version flag [0]. This should allow you run migration up without moving files around directories. > I wasn't really sure what the actual outcome would look like If I have something like this in a migration script Agree that we can do a better job with the documentation for squash command. I will add more examples. The current implementation does a schema only dump from the local database, created by running local migration files. Any insert statements will be excluded from the dump. I believe this is not the correct behaviour so I've filed a bu