## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Updated examples and guides to use Supabase publishable (client) keys
instead of anon keys for client-side usage across frameworks and
platforms.
* Renamed environment variable examples and .env templates to reflect
publishable key naming.
* Adjusted sample requests and client-init examples to send/use the
publishable key via the apikey header where applicable.
* Updated references from service_role to secret for server-side
credential guidance.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: fadymak <fady@fadymak.com>
* Use latest 2.x version of `@supabase/supabase-js` in all examples
* Use `latest` version of `@supabase/ssr` in all examples
* Remove lock files from examples
* Add examples lock files in .gitignore
The rationale is:
- Lock files are not actively maintained/updated (or the versions in the
package.json files for that matter)
- They pin an arbitrary version (from the end-user perspective)
- Removes the need to manually update the versions and reinstall
- Consistency
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **Chores**
* Broadened Supabase SDK dependency version constraints across example
projects for greater flexibility with compatible updates
* Updated some SSR package dependencies to track latest releases
* Added gitignore rules for dependency lock files in example directories
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
### What kind of change does this PR introduce?
Bug fix — corrects a TypeScript initialization error in the Angular user
management tutorial example.
### What is the current behavior?
In the Angular tutorial's `AuthComponent`, `signInForm` is declared with
a non-null assertion (`signInForm!: FormGroup`) and initialized inside
`ngOnInit()`. This causes a TypeScript strict-mode error because
`formBuilder` is used before the constructor runs. Developers following
the tutorial encounter:
> Property 'formBuilder' is used before being initialized.
### What is the new behavior?
`signInForm` is now initialized in the constructor, matching the pattern
already used by `AccountComponent` in the same example project. The
non-null assertion is removed since the property is properly assigned
during construction.
### Changes
**`examples/user-management/angular-user-management/src/app/auth/auth.component.ts`**
- Moved `signInForm` initialization from `ngOnInit()` into the
constructor
- Removed non-null assertion operator (`!`) from `signInForm`
declaration
- Reordered property declarations for consistency (`loading` before
`signInForm`)
### Additional context
The sibling `AccountComponent` already follows the correct pattern —
initializing `updateProfileForm` inside the constructor (line 35). This
PR aligns `AuthComponent` with that established convention.
Closes#34392
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a loading indicator state to the authentication form.
* **Refactor**
* Restructured form initialization logic for improved component setup.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
