Merge branch 'main' of github.com:redwoodjs/redwood into feat/rw-uplo…

…ads-extension

* 'main' of github.com:redwoodjs/redwood: (52 commits)
  linting: enable 'typescript-eslint/await-thenable' rule (redwoodjs#11311)
  refactor(api): Add conditional exports to package.json (redwoodjs#11307)
  chore(readme): Add my middle initials (redwoodjs#11310)
  chore(README): Fix formatting. One row (redwoodjs#11309)
  chore(README): Move Kris from Maintainer to Alumni (redwoodjs#11308)
  fix(codemods): Move away from babel for building package (redwoodjs#11306)
  fix(api): Move away from babel for building package (redwoodjs#11305)
  fix(internal): Move away from babel for building package (redwoodjs#11304)
  fix(auth-providers): Move away from babel for building 'api' packages (redwoodjs#11301)
  fix(auth-providers): Move away from babel for building 'setup' packages  (redwoodjs#11303)
  chore(deps): Remove webpack related dependencies (redwoodjs#11299)
  chore(build): build core with esbuild (redwoodjs#11298)
  chore(exec test): Clean up (redwoodjs#11302)
  Detect/resolve ambiguous script names (redwoodjs#9848)
  chore(lint): tidy up the prettier ignore (redwoodjs#11297)
  feat(context): Build and publish package as dual esm/cjs (redwoodjs#11294)
  chore(lint): fix prettier configs and ignores (redwoodjs#11295)
  chore(docs): update prettier config and format docs content (redwoodjs#11293)
  chore(check): Refactor 'yarn check' away from being a standalone node script  (redwoodjs#11292)
  chore: delete crowdin config file (redwoodjs#11291)
  ...

.changesets/10064.md

@@ -1,7 +1,8 @@
 - Add Storybook (Vite) framework package (#10064) by @arimendelow
 
 Adds:
+
 - Storybook framework package for using Storybook with Vite.
 - CLI package (command: `yarn rw sbv`) for running Storybook using Vite. CLI package additionally creates Mock Service Worker, and, on first run, the project-side Storybook config files.
 
-Current Storybook (Webpack) users will need to manually migrate any additional Storybook config (mocks, etc.). The primary user-facing difference between the old and new Storybook integrations is that the config used by the old one lives in the `@redwoodjs/testing` package, and the config used by this new one lives in the user's `web/.storybook` directory.
+Current Storybook (Webpack) users will need to manually migrate any additional Storybook config (mocks, etc.). The primary user-facing difference between the old and new Storybook integrations is that the config used by the old one lives in the `@redwoodjs/testing` package, and the config used by this new one lives in the user's `web/.storybook` directory.

.changesets/10179.md

@@ -5,7 +5,7 @@ This PR upgrades Redwood internally to Prettier v3. We believe this won't have a
 If you have Tailwind CSS configured, can upgrade `prettier-plugin-tailwindcss` to a version later than `0.4.1` if you make a few changes:
 
 - Change `prettier.config.js` to `prettier.config.mjs` (js -> mjs)
-- `export default` instead of `module.exports` 
+- `export default` instead of `module.exports`
 - `await import('...')` any plugins instead of `require('...')`
 
 Here's an example of an updated `prettier.config.mjs` to work with `prettier-plugin-tailwindcss@^0.5.12`:

.changesets/10266.md

@@ -1,6 +1,5 @@
 - chore(linting): Update versions and avoid `{}` (#10266) by @Josh-Walker-GM
 
-This PR updates the versions of the `eslint` and the `@typescript-eslint` packages from v5 to v7. 
+This PR updates the versions of the `eslint` and the `@typescript-eslint` packages from v5 to v7.
 
 This is a major upgrade of the `@typescript-eslint` package and although we think it is unlikely to introduce a breaking change for you we would recommend that you read the associated documentation. The v6 upgrade can be found [here](https://typescript-eslint.io/blog/announcing-typescript-eslint-v6/) and the v7 one [here](https://typescript-eslint.io/blog/announcing-typescript-eslint-v7/).
-

.changesets/10342.md

@@ -23,7 +23,6 @@ The `<NavLink>` above would get the following classes if it was the active link
 
 That same `<NavLink>` now only gets the `activeClassName` classes `active inline-block rounded-t-lg border-b-2 border-blue-600 p-4 text-blue-600 dark:border-blue-500 dark:text-blue-500`
 
-
 ## Breaking
 
 If you were relying on the merging behavior you will now have to copy all classes from `className` and also include them in `activeClassName`.

.changesets/10344.md

@@ -5,6 +5,7 @@ Add intellisense and color support for not only `className` (which is enabled by
 ## Manual Instructions
 
 If you already have TW set up and want to enable this, open `.vscode/settings.json` and add this:
+
 ```json
 "tailwindCSS": {
   "classAttributes": ["class", "className", "activeClassName", "errorClassName"]

.changesets/10395.md

@@ -1,34 +1,38 @@
 - Middleware Routing & `registerMiddleware` (#10395) by @dac09
 
-Implements the new syntax of using Middleware after discussion. This sets us up for doing Auth better, but also for implementations like OG Image generation. 
+Implements the new syntax of using Middleware after discussion. This sets us up for doing Auth better, but also for implementations like OG Image generation.
 
 ```js
 export const registerMiddleware = async () => {
-	return [
-		dbAuthMiddleware(),
-		[new OgMiddleware({ rootFilename: 'index' }), [ '/:route.:extension']]
-	]
+  return [
+    dbAuthMiddleware(),
+    [new OgMiddleware({ rootFilename: 'index' }), ['/:route.:extension']],
+  ]
 }
 ```
 
 **Features**
+
 - [x] Registering middleware with above syntax
 - [x] Chaining multiple middleware by passing array of middleware, or tuples
 - [x] Defining the route patterns to match in the find-my-way syntax
 
---- 
+---
+
 **What syntax are you using for the route patterns?**
 After discussion that Regexes are slow and unwieldy, I did some research and comparisons here: https://www.notion.so/redwoodjs/Middleware-Route-patterns-0f1c5587b4134073adfae896a782b5ea?pvs=
 
 This implementation uses https://github.com/delvedor/find-my-way - which is the Fastify version - but still keeps us decoupled from Fastify (see implementation, or document for why).
 
 **Important for understanding**
 Quoting from find-my-way docs:
+
 > The nodes are matched in the following order:
+
     static
     parametric node with static ending
     parametric(regex)/multi-parametric
     parametric
     wildcard
 
-Which means, if you have a more specific one - example you have `[mw1, `*`]` and `[mw2, '/refresh_auth']` - then a request to /refresh_auth will ONLY trigger mw2. This is sort of counter intuitive, but them are the rules with fmw. 
+Which means, if you have a more specific one - example you have `[mw1, `\*`]` and `[mw2, '/refresh_auth']` - then a request to /refresh_auth will ONLY trigger mw2. This is sort of counter intuitive, but them are the rules with fmw.

.changesets/10420.md

@@ -1,12 +1,8 @@
-- feat: [Auth] Common AuthProvider & use* changes for middleware auth #10420 by @dac09 and @dthyresson
+- feat: [Auth] Common AuthProvider & use\* changes for middleware auth #10420 by @dac09 and @dthyresson
 
 * First step of supporting Auth using middleware
 * Ensure backwards compatibility with non-SSR auth
 
 ### Breaking Change
 
 Removes `skipFetchCurrentUser` which was used by the no longer existing nHost auth provider, but could potentially have been used by custom auth.
-
-
-
-

.changesets/10441.md

@@ -1,10 +1,10 @@
 - feat(og-gen): Update implementation of useLocation | Update App template (#10441) by @dac09
-**Updated App.tsx template**
-We modified the `App.tsx` template to accept possible children, and render them if present. This lets the og:image handler inject your component into the Document tree, without including the entire Router, but still style your og:image component using whatever you used to style the rest of your app (Tailwind, perhaps?)
+  **Updated App.tsx template**
+  We modified the `App.tsx` template to accept possible children, and render them if present. This lets the og:image handler inject your component into the Document tree, without including the entire Router, but still style your og:image component using whatever you used to style the rest of your app (Tailwind, perhaps?)
 
 **Updated useLocation implementation**
 We also modified the `useLocation()` hook to now return everything that the [URL API](https://developer.mozilla.org/en-US/docs/Web/API/URL) returns. Previously it only returned three attributes of the url (pathname, search, hash), now it returns everything available to a call to `new URL()` (origin, href, searchParams, etc.).
 
 The reason for this is now that we have SSR, we can get access to more details in the hook - in this case we needed origin
 
-Both changes should be non-breaking! 
+Both changes should be non-breaking!

.changesets/10444.md

@@ -1,4 +1,5 @@
 - feat(server-auth): Part 1/3: dbAuth middleware support (web side changes) (#10444) by @dac09
-Adds ability to `createMiddlewareAuth` in dbAuth client which:
+  Adds ability to `createMiddlewareAuth` in dbAuth client which:
+
 1. Updates the dbAuth web client to speak to middleware instead of graphql
 2. Implements fetching current user from middleware

.changesets/10453.md

@@ -1,5 +1,5 @@
 - feat: Remove `--performance` option from `yarn rw build` (#10453) by @Josh-Walker-GM
 
-This change removes the `--performance` flag from the `yarn rw build` command. It will no longer be available to use and the CLI will no longer accept this flag being passed in. 
+This change removes the `--performance` flag from the `yarn rw build` command. It will no longer be available to use and the CLI will no longer accept this flag being passed in.
 
-Additionally, the associated webpack config (`@redwoodjs/core/config/webpack.perf.js`) has been removed so it can no longer be imported if you were doing so. 
+Additionally, the associated webpack config (`@redwoodjs/core/config/webpack.perf.js`) has been removed so it can no longer be imported if you were doing so.

.changesets/10457.md

@@ -1,28 +1,30 @@
-- feat(server-auth): dbAuth 3/3 -  handle login, logout, signup, etc. requests if forwarded from middleware (#10457) by @dac09
+- feat(server-auth): dbAuth 3/3 - handle login, logout, signup, etc. requests if forwarded from middleware (#10457) by @dac09
 
-This PR updates the DbAuthHandler class to handle requests forwarded from middleware, so it can generate responses for login, logout, signup, etc. These are POST requests - it used to be to the `/auth` function, but now they will be captured by dbAuth middleware and forwarded onto DbAuthHandler. 
+This PR updates the DbAuthHandler class to handle requests forwarded from middleware, so it can generate responses for login, logout, signup, etc. These are POST requests - it used to be to the `/auth` function, but now they will be captured by dbAuth middleware and forwarded onto DbAuthHandler.
 
 **High level changes:**
+
 - use the `Headers` class in each of the "method" responses. This allows us to set multi-value headers like Set-Cookie. A simple object would not. See type `AuthMethodOutput`
-- extracts `buildResponse` into a testable function and adds test. For `Set-Cookie` headers we return an array of strings. 
+- extracts `buildResponse` into a testable function and adds test. For `Set-Cookie` headers we return an array of strings.
 
 In the middleware here's the code I had for the final conversion:
-```ts
-    if (AUTHHANDLER_REQUEST) {
-      const output = await dbAuthHandler(req)
 
-      const finalHeaders = new Headers()
-      Object.entries(output.headers).forEach(([key, value]) => {
-        if (Array.isArray(value)) {
-          value.forEach((v) => finalHeaders.append(key, v))
-        } else {
-          finalHeaders.append(key, value)
-        }
-      })
+```ts
+if (AUTHHANDLER_REQUEST) {
+  const output = await dbAuthHandler(req)
 
-      return new MiddlewareResponse(output.body, {
-        headers: finalHeaders,
-        status: output.statusCode,
-      })
+  const finalHeaders = new Headers()
+  Object.entries(output.headers).forEach(([key, value]) => {
+    if (Array.isArray(value)) {
+      value.forEach((v) => finalHeaders.append(key, v))
+    } else {
+      finalHeaders.append(key, value)
     }
+  })
+
+  return new MiddlewareResponse(output.body, {
+    headers: finalHeaders,
+    status: output.statusCode,
+  })
+}
 ```

.changesets/10460.md

@@ -1,8 +1,8 @@
 - chore(dbauth-mw): Refactor web side dbAuth creation (#10460) by @dac09
 
-This PR changes how the webside auth is initialised, by removing the `createMiddlewareAuth` function, instead it just detects it internally. 
+This PR changes how the webside auth is initialised, by removing the `createMiddlewareAuth` function, instead it just detects it internally.
 
-For dbAuth this is what it will looks like: 
+For dbAuth this is what it will looks like:
 
 ```js:web/src/auth.ts
 import {
@@ -23,13 +23,16 @@ export const { AuthProvider, useAuth } = createAuth(dbAuthClient)
 For other auth providers we are going to export a similar looking function:
 
 ```js
-import { createAuth, createSupabaseAuthClient } from '@redwoodjs/auth-supabase-web'
+import {
+  createAuth,
+  createSupabaseAuthClient,
+} from '@redwoodjs/auth-supabase-web'
 
 // This function is new, and just wraps creating supabase👇
 const supabaseClient = createSupabaseAuthClient({
   supabaseUrl: process.env.SUPABASE_URL || '',
   supabaseKey: process.env.SUPABASE_KEY || '',
-  middleware: true
+  middleware: true,
 })
 
 export const { AuthProvider, useAuth } = createAuth(supabaseClient)

.changesets/10464.md

@@ -4,7 +4,7 @@ We were using both `index.ts` and `router.tsx` as barrel export files. We should
 
 This is a breaking change for anyone who does `import ... from '@redwoodjs/router/dist/router'` in their project. Which hopefully isn't very many.
 
- - The quick fix is to find the original export and pull from there instead
- - The real fix is to talk to us on the core team and see if we can provide an
-   official way of solving it instead of relying on internal implementation
-   details 🙂 
+- The quick fix is to find the original export and pull from there instead
+- The real fix is to talk to us on the core team and see if we can provide an
+  official way of solving it instead of relying on internal implementation
+  details 🙂

.changesets/10465.md

@@ -2,12 +2,12 @@
 
 **1. Updates `getAuthenticationContext` to parse the cookie header and pass it to authDecoder.**
 
-Note that the authentication context itself does not pull out the token from cookies, because with some providers (e.g. supabase) - we don't know the name of the cookie. This is left to the authDecoder implementation. 
+Note that the authentication context itself does not pull out the token from cookies, because with some providers (e.g. supabase) - we don't know the name of the cookie. This is left to the authDecoder implementation.
 
-The return type from this function is actually just a deserialized cookie header i.e. 
+The return type from this function is actually just a deserialized cookie header i.e.
 `cookie: auth-provider=one; session=xx/yy/zz; somethingElse=bsbs` => `{ 'auth-provider': 'one',  session: 'xx/yy/zz', somethingElse: 'bsbs'`
 
-**2. Retains support for header/token based auth** 
+**2. Retains support for header/token based auth**
 See test on line 259 of `packages/api/src/auth/__tests__/getAuthenticationContext.test.ts`. If a the `authorization` and `auth-provider` headers are passed in the request (as we do for SPA based auth) - then cookies will take precedence.
 
-The end result is that graphql requests will now work with middleware-based auth providers! 
+The end result is that graphql requests will now work with middleware-based auth providers!

.changesets/10469.md

@@ -1,45 +1,49 @@
-- feat(og-gen): Implement middleware and hooks  (#10469) by @dac09
+- feat(og-gen): Implement middleware and hooks (#10469) by @dac09
 
-The OG Gen saga continues with  @cannikin and @dac09 ⚔️
+The OG Gen saga continues with @cannikin and @dac09 ⚔️
 
 This PR:
+
 - adds OgImageMiddleware and Hooks to `@redwoodjs/og-gen`, complete with tests
 
 ⚠️ Template changes:
+
 - updates entry.client template to pass in Routes to App
 - updates App to take children (i.e. Routes)
 
 This is so that we can pass the OG component to be rendered _with_ your App's CSS setup.
 
-
 **How to use this?**
 
 1. **Registering the middleware:**
-    ```ts 
-    import OgImageMiddleware from '@redwoodjs/ogimage-gen/middleware'
 
-    export const registerMiddleware = () => {
-      const ogMw = new OgImageMiddleware({
-        App,
-        Document,
-      })
+   ```ts
+   import OgImageMiddleware from '@redwoodjs/ogimage-gen/middleware'
 
-      return [ogMw]
-    }
-    ```
+   export const registerMiddleware = () => {
+     const ogMw = new OgImageMiddleware({
+       App,
+       Document,
+     })
+
+     return [ogMw]
+   }
+   ```
 
 2. Configure your `vite.config.ts`
-    ```ts
-    import vitePluginOgImageGen from '@redwoodjs/ogimage-gen/plugin'
 
-    const viteConfig: UserConfig = {
-      // 👇 so it builds your OG components
-      plugins: [redwood(), vitePluginOgImageGen()],
-    }
+   ```ts
+   import vitePluginOgImageGen from '@redwoodjs/ogimage-gen/plugin'
+
+   const viteConfig: UserConfig = {
+     // 👇 so it builds your OG components
+     plugins: [redwood(), vitePluginOgImageGen()],
+   }
+
+   export default defineConfig(viteConfig)
+   ```
 
-    export default defineConfig(viteConfig)
-    ```
 3. Add your OG Image component next to the page it's for
-e.g. web/src/pages/AboutPage/AboutPage.png.tsx
+   e.g. web/src/pages/AboutPage/AboutPage.png.tsx
 
 4. Use hooks on AboutPage to generate the ogURL

.changesets/10493.md

@@ -10,10 +10,9 @@ const myCookie = mwRequest.cookies.get('myCookie')
 const actualValue = myCookie.value
 ```
 
-This is unwieldy, and feels unergonomic for the 98% of cases where `get` will be used to just see the value. 
+This is unwieldy, and feels unergonomic for the 98% of cases where `get` will be used to just see the value.
 
 **How do I still see the options of the cookie?**
 You can still access all the details of the cookie by doing `cookie.entries`. I don't really have a case for this yet, so let's not optimise for this case, but we know it's possible!
 
-
 This is me just stabilizing the API for Middleware stuff, before we ship it out of experimental

.changesets/10498.md

@@ -6,5 +6,3 @@ This is because the dbauth-provider-web packages are still CJS only. When import
 
 **2. Updates the default auth provider state for middleware auth**
 Middleware auth default state is _almost_ the same as SPA default auth state. Except that loading is always false! Otherwise you can get stuck in a loading state forever.
-
-

.changesets/10499.md

@@ -2,11 +2,9 @@
 
 Implement Supabase Auth Middleware to authenticate server-side requests.
 
-* Adds middleware to the Supabase auth-providers package.
-* createSupabaseAuthMiddleware is responsible for authenticating Supabase requests
-* It does so by checking if the request has a supabase auth-provider header, and then uses the authDecoder to verify the session cookie using the Supabase ServerAuthClient and returning a decoded access token -- or throwing an exception if the session cookie is invalid
-* Once the middleware has the decoded JWT, it hands that to the provided getCurrentUser from he user's project to return the information about authenticated user
-* Lastly, it sets serverAuthState with user and metadata info to know the request isAuthenticated
-* If the session is invalid or the cookie tampered with such that the access token cannot be verified, serverAuthState is cleared as are the auth provider and Supabase cookies
-
-
+- Adds middleware to the Supabase auth-providers package.
+- createSupabaseAuthMiddleware is responsible for authenticating Supabase requests
+- It does so by checking if the request has a supabase auth-provider header, and then uses the authDecoder to verify the session cookie using the Supabase ServerAuthClient and returning a decoded access token -- or throwing an exception if the session cookie is invalid
+- Once the middleware has the decoded JWT, it hands that to the provided getCurrentUser from he user's project to return the information about authenticated user
+- Lastly, it sets serverAuthState with user and metadata info to know the request isAuthenticated
+- If the session is invalid or the cookie tampered with such that the access token cannot be verified, serverAuthState is cleared as are the auth provider and Supabase cookies

.changesets/10502.md

@@ -1,2 +1,2 @@
 - fix(dbauth-mw): Unset cookie instead of clearing (#10502) by @dac09
-Updates dbAuth middleware implementation to _unset_ the cookies, instead of clearing them.
+  Updates dbAuth middleware implementation to _unset_ the cookies, instead of clearing them.

.changesets/10520.md

@@ -1,3 +1,3 @@
 - feat(eslint): Disable restricted $api imports for entryserver (#10520) by @dac09
 
-With the introduction of middleware, it's pretty common to import things from the $api side. This is a non-issue as entry.server.{jsx,tsx} is not part of the client bundle we generate. 
+With the introduction of middleware, it's pretty common to import things from the $api side. This is a non-issue as entry.server.{jsx,tsx} is not part of the client bundle we generate.

.changesets/10522.md

@@ -5,7 +5,7 @@
 In `web/src/auth.ts`:
 
 ```
-// 👇 notice where this is imported from! 
+// 👇 notice where this is imported from!
 import { createBrowserClient } from '@supabase/ssr'
 
 import { createAuth } from '@redwoodjs/auth-supabase-web'

.changesets/10538.md

@@ -1,6 +1,7 @@
 - fix(serverauth): Export dbAuthMiddleware as default export to match supabase (#10538) by @dac09
 
 An example:
+
 ```js
 //before
 import { createDbAuthMiddleware } from '@redwoodjs/auth-dbauth-middleware'