Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(deps): update astro monorepo - autoclosed #379

Closed
wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented May 12, 2024

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@astrojs/react (source) 3.3.1 -> 3.6.0 age adoption passing confidence
@astrojs/svelte (source) 5.4.0 -> 5.6.0 age adoption passing confidence
astro (source) 4.3.5 -> 4.10.3 age adoption passing confidence

Release Notes

withastro/astro (@​astrojs/react)

v3.6.0

Compare Source

Minor Changes
  • #​11234 4385bf7 Thanks @​ematipico! - Adds a new function called addServerRenderer to the Container API. Use this function to manually store renderers inside the instance of your container.

    This new function should be preferred when using the Container API in environments like on-demand pages:

    import type { APIRoute } from 'astro';
    import { experimental_AstroContainer } from 'astro/container';
    import reactRenderer from '@​astrojs/react/server.js';
    import vueRenderer from '@​astrojs/vue/server.js';
    import ReactComponent from '../components/button.jsx';
    import VueComponent from '../components/button.vue';
    
    // MDX runtime is contained inside the Astro core
    import mdxRenderer from 'astro/jsx/server.js';
    
    // In case you need to import a custom renderer
    import customRenderer from '../renderers/customRenderer.js';
    
    export const GET: APIRoute = async (ctx) => {
      const container = await experimental_AstroContainer.create();
      container.addServerRenderer({ renderer: reactRenderer });
      container.addServerRenderer({ renderer: vueRenderer });
      container.addServerRenderer({ renderer: customRenderer });
      // You can pass a custom name too
      container.addServerRenderer({
        name: 'customRenderer',
        renderer: customRenderer,
      });
      const vueComponent = await container.renderToString(VueComponent);
      return await container.renderToResponse(Component);
    };

v3.5.0

Compare Source

Minor Changes
  • #​11144 803dd80 Thanks @​ematipico! - The integration now exposes a function called getContainerRenderer, that can be used inside the Container APIs to load the relative renderer.

    import { experimental_AstroContainer as AstroContainer } from 'astro/container';
    import ReactWrapper from '../src/components/ReactWrapper.astro';
    import { loadRenderers } from 'astro:container';
    import { getContainerRenderer } from '@​astrojs/react';
    
    test('ReactWrapper with react renderer', async () => {
      const renderers = await loadRenderers([getContainerRenderer()]);
      const container = await AstroContainer.create({
        renderers,
      });
      const result = await container.renderToString(ReactWrapper);
    
      expect(result).toContain('Counter');
      expect(result).toContain('Count: <!-- -->5');
    });

v3.4.0

Compare Source

Minor Changes
  • #​11071 8ca7c73 Thanks @​bholmesdev! - Adds two new functions experimental_getActionState() and experimental_withState() to support the React 19 useActionState() hook when using Astro Actions. This introduces progressive enhancement when calling an Action with the withState() utility.

    This example calls a like action that accepts a postId and returns the number of likes. Pass this action to the experimental_withState() function to apply progressive enhancement info, and apply to useActionState() to track the result:

    import { actions } from 'astro:actions';
    import { experimental_withState } from '@&#8203;astrojs/react/actions';
    
    export function Like({ postId }: { postId: string }) {
      const [state, action, pending] = useActionState(
        experimental_withState(actions.like),
        0 // initial likes
      );
    
      return (
        <form action={action}>
          <input type="hidden" name="postId" value={postId} />
          <button disabled={pending}>{state} ❤️</button>
        </form>
      );
    }

    You can also access the state stored by useActionState() from your action handler. Call experimental_getActionState() with the API context, and optionally apply a type to the result:

    import { defineAction, z } from 'astro:actions';
    import { experimental_getActionState } from '@&#8203;astrojs/react/actions';
    
    export const server = {
      like: defineAction({
        input: z.object({
          postId: z.string(),
        }),
        handler: async ({ postId }, ctx) => {
          const currentLikes = experimental_getActionState<number>(ctx);
          // write to database
          return currentLikes + 1;
        },
      }),
    };

v3.3.4

Compare Source

Patch Changes

v3.3.3

Compare Source

Patch Changes

v3.3.2

Compare Source

Patch Changes
withastro/astro (@​astrojs/svelte)

v5.6.0

Compare Source

Minor Changes
  • #​11234 4385bf7 Thanks @​ematipico! - Adds a new function called addServerRenderer to the Container API. Use this function to manually store renderers inside the instance of your container.

    This new function should be preferred when using the Container API in environments like on-demand pages:

    import type { APIRoute } from 'astro';
    import { experimental_AstroContainer } from 'astro/container';
    import reactRenderer from '@&#8203;astrojs/react/server.js';
    import vueRenderer from '@&#8203;astrojs/vue/server.js';
    import ReactComponent from '../components/button.jsx';
    import VueComponent from '../components/button.vue';
    
    // MDX runtime is contained inside the Astro core
    import mdxRenderer from 'astro/jsx/server.js';
    
    // In case you need to import a custom renderer
    import customRenderer from '../renderers/customRenderer.js';
    
    export const GET: APIRoute = async (ctx) => {
      const container = await experimental_AstroContainer.create();
      container.addServerRenderer({ renderer: reactRenderer });
      container.addServerRenderer({ renderer: vueRenderer });
      container.addServerRenderer({ renderer: customRenderer });
      // You can pass a custom name too
      container.addServerRenderer({
        name: 'customRenderer',
        renderer: customRenderer,
      });
      const vueComponent = await container.renderToString(VueComponent);
      return await container.renderToResponse(Component);
    };

v5.5.0

Compare Source

Minor Changes
  • #​11144 803dd80 Thanks @​ematipico! - The integration now exposes a function called getContainerRenderer, that can be used inside the Container APIs to load the relative renderer.

    import { experimental_AstroContainer as AstroContainer } from 'astro/container';
    import ReactWrapper from '../src/components/ReactWrapper.astro';
    import { loadRenderers } from 'astro:container';
    import { getContainerRenderer } from '@&#8203;astrojs/react';
    
    test('ReactWrapper with react renderer', async () => {
      const renderers = await loadRenderers([getContainerRenderer()]);
      const container = await AstroContainer.create({
        renderers,
      });
      const result = await container.renderToString(ReactWrapper);
    
      expect(result).toContain('Counter');
      expect(result).toContain('Count: <!-- -->5');
    });
withastro/astro (astro)

v4.10.3

Compare Source

Patch Changes
  • #​11213 94ac7ef Thanks @​florian-lefebvre! - Removes the PUBLIC_ prefix constraint for astro:env public variables

  • #​11213 94ac7ef Thanks @​florian-lefebvre! - BREAKING CHANGE to the experimental astro:env feature only

    Server secrets specified in the schema must now be imported from astro:env/server. Using getSecret() is no longer required to use these environment variables in your schema:

    - import { getSecret } from 'astro:env/server'
    - const API_SECRET = getSecret("API_SECRET")
    + import { API_SECRET } from 'astro:env/server'

    Note that using getSecret() with these keys is still possible, but no longer involves any special handling and the raw value will be returned, just like retrieving secrets not specified in your schema.

  • #​11234 4385bf7 Thanks @​ematipico! - Adds a new function called addServerRenderer to the Container API. Use this function to manually store renderers inside the instance of your container.

    This new function should be preferred when using the Container API in environments like on-demand pages:

    import type { APIRoute } from 'astro';
    import { experimental_AstroContainer } from 'astro/container';
    import reactRenderer from '@&#8203;astrojs/react/server.js';
    import vueRenderer from '@&#8203;astrojs/vue/server.js';
    import ReactComponent from '../components/button.jsx';
    import VueComponent from '../components/button.vue';
    
    // MDX runtime is contained inside the Astro core
    import mdxRenderer from 'astro/jsx/server.js';
    
    // In case you need to import a custom renderer
    import customRenderer from '../renderers/customRenderer.js';
    
    export const GET: APIRoute = async (ctx) => {
      const container = await experimental_AstroContainer.create();
      container.addServerRenderer({ renderer: reactRenderer });
      container.addServerRenderer({ renderer: vueRenderer });
      container.addServerRenderer({ renderer: customRenderer });
      // You can pass a custom name too
      container.addServerRenderer({
        name: 'customRenderer',
        renderer: customRenderer,
      });
      const vueComponent = await container.renderToString(VueComponent);
      return await container.renderToResponse(Component);
    };
  • #​11249 de60c69 Thanks @​markgaze! - Fixes a performance issue with JSON schema generation

  • #​11242 e4fc2a0 Thanks @​ematipico! - Fixes a case where the virtual module astro:container wasn't resolved

  • #​11236 39bc3a5 Thanks @​ascorbic! - Fixes a case where symlinked content collection directories were not correctly resolved

  • #​11258 d996db6 Thanks @​ascorbic! - Adds a new error RewriteWithBodyUsed that throws when Astro.rewrite is used after the request body has already been read.

  • #​11243 ba2b14c Thanks @​V3RON! - Fixes a prerendering issue for libraries in node_modules when a folder with an underscore is in the path.

  • #​11244 d07d2f7 Thanks @​ematipico! - Improves the developer experience of the custom 500.astro page in development mode.

    Before, in development, an error thrown during the rendering phase would display the default error overlay, even when users had the 500.astro page.

    Now, the development server will display the 500.astro and the original error is logged in the console.

  • #​11240 2851b0a Thanks @​ascorbic! - Ignores query strings in module identifiers when matching ".astro" file extensions in Vite plugin

  • #​11245 e22be22 Thanks @​bluwy! - Refactors prerendering chunk handling to correctly remove unused code during the SSR runtime

v4.10.2

Compare Source

Patch Changes
  • #​11231 58d7dbb Thanks @​ematipico! - Fixes a regression for getViteConfig, where the inline config wasn't merged in the final config.

  • #​11228 1e293a1 Thanks @​ascorbic! - Updates getCollection() to always return a cloned array

  • #​11207 7d9aac3 Thanks @​ematipico! - Fixes an issue in the rewriting logic where old data was not purged during the rewrite flow. This caused some false positives when checking the validity of URL path names during the rendering phase.

  • #​11189 75a8fe7 Thanks @​ematipico! - Improve error message when using getLocaleByPath on path that doesn't contain any locales.

  • #​11195 0a6ab6f Thanks @​florian-lefebvre! - Adds support for enums to astro:env

    You can now call envField.enum:

    import { defineConfig, envField } from 'astro/config';
    
    export default defineConfig({
      experimental: {
        env: {
          schema: {
            API_VERSION: envField.enum({
              context: 'server',
              access: 'secret',
              values: ['v1', 'v2'],
            }),
          },
        },
      },
    });
  • #​11210 66fc028 Thanks @​matthewp! - Close the iterator only after rendering is complete

  • #​11195 0a6ab6f Thanks @​florian-lefebvre! - Adds additional validation options to astro:env

    astro:env schema datatypes string and number now have new optional validation rules:

    import { defineConfig, envField } from 'astro/config';
    
    export default defineConfig({
      experimental: {
        env: {
          schema: {
            FOO: envField.string({
              // ...
              max: 32,
              min: 3,
              length: 12,
              url: true,
              includes: 'foo',
              startsWith: 'bar',
              endsWith: 'baz',
            }),
            BAR: envField.number({
              // ...
              gt: 2,
              min: 3,
              lt: 10,
              max: 9,
              int: true,
            }),
          },
        },
      },
    });
  • #​11211 97724da Thanks @​matthewp! - Let middleware handle the original request URL

  • #​10607 7327c6a Thanks @​frankbits! - Fixes an issue where a leading slash created incorrect conflict resolution between pages generated from static routes and catch-all dynamic routes

v4.10.1

Compare Source

Patch Changes

v4.10.0

Compare Source

Minor Changes
  • #​10974 2668ef9 Thanks @​florian-lefebvre! - Adds experimental support for the astro:env API.

    The astro:env API lets you configure a type-safe schema for your environment variables, and indicate whether they should be available on the server or the client. Import and use your defined variables from the appropriate /client or /server module:

v4.9.3

Compare Source

Patch Changes
  • #​11171 ff8004f Thanks @​Princesseuh! - Guard globalThis.astroAsset usage in proxy code to avoid errors in wonky situations

  • #​11178 1734c49 Thanks @​theoephraim! - Improves isPromise utility to check the presence of then on an object before trying to access it - which can cause undesired side-effects on Proxy objects

  • #​11183 3cfa2ac Thanks @​66Leo66! - Suggest pnpm dlx instead of pnpx in update check.

  • #​11147 2d93902 Thanks @​kitschpatrol! - Fixes invalid MIME types in Picture source elements for jpg and svg extensions, which was preventing otherwise valid source variations from being shown by the browser

  • #​11141 19df89f Thanks @​ematipico! - Fixes an internal error that prevented the AstroContainer to render the Content component.

    You can now write code similar to the following to render content collections:

    const entry = await getEntry(collection, slug);
    const { Content } = await entry.render();
    const content = await container.renderToString(Content);
  • #​11170 ba20c71 Thanks @​matthewp! - Retain client scripts in content cache

v4.9.2

Compare Source

Patch Changes
  • #​11138 98e0372 Thanks @​ematipico! - You can now pass props when rendering a component using the Container APIs:

    import { experimental_AstroContainer as AstroContainer } from 'astro/container';
    import Card from '../src/components/Card.astro';
    
    const container = await AstroContainer.create();
    const result = await container.renderToString(Card, {
      props: {
        someState: true,
      },
    });

v4.9.1

Compare Source

Patch Changes

v4.9.0

Compare Source

Minor Changes
  • #​11051 12a1bcc Thanks @​ematipico! - Introduces an experimental Container API to render .astro components in isolation.

    This API introduces three new functions to allow you to create a new container and render an Astro component returning either a string or a Response:

    • create(): creates a new instance of the container.
    • renderToString(): renders a component and return a string.
    • renderToResponse(): renders a component and returns the Response emitted by the rendering phase.

    The first supported use of this new API is to enable unit testing. For example, with vitest, you can create a container to render your component with test data and check the result:

    import { experimental_AstroContainer as AstroContainer } from 'astro/container';
    import { expect, test } from 'vitest';
    import Card from '../src/components/Card.astro';
    
    test('Card with slots', async () => {
      const container = await AstroContainer.create();
      const result = await container.renderToString(Card, {
        slots: {
          default: 'Card content',
        },
      });
    
      expect(result).toContain('This is a card');
      expect(result).toContain('Card content');
    });

    For a complete reference, see the Container API docs.

    For a feature overview, and to give feedback on this experimental API, see the Container API roadmap discussion.

  • #​11021 2d4c8fa Thanks @​ematipico! - The CSRF protection feature that was introduced behind a flag in v4.6.0 is no longer experimental and is available for general use.

    To enable the stable version, add the new top-level security option in astro.config.mjs. If you were previously using the experimental version of this feature, also delete the experimental flag:

    export default defineConfig({
    -  experimental: {
    -    security: {
    -      csrfProtection: {
    -        origin: true
    -      }
    -    }
    -  },
    +  security: {
    +    checkOrigin: true
    +  }
    })

    Enabling this setting performs a check that the "origin" header, automatically passed by all modern browsers, matches the URL sent by each Request.

    This check is executed only for pages rendered on demand, and only for the requests POST, PATCH, DELETE and PUT with one of the following "content-type" headers: 'application/x-www-form-urlencoded', 'multipart/form-data', 'text/plain'.

    If the "origin" header doesn't match the pathname of the request, Astro will return a 403 status code and won't render the page.

    For more information, see the security configuration docs.

  • #​11022 be68ab4 Thanks @​ematipico! - The i18nDomains routing feature introduced behind a flag in v3.4.0 is no longer experimental and is available for general use.

    This routing option allows you to configure different domains for individual locales in entirely server-rendered projects using the @​astrojs/node or @​astrojs/vercel adapter with a site configured.

    If you were using this feature, please remove the experimental flag from your Astro config:

    import { defineConfig } from 'astro'
    
    export default defineConfig({
    -  experimental: {
    -    i18nDomains: true,
    -  }
    })

    If you have been waiting for stabilization before using this routing option, you can now do so.

    Please see the internationalization docs for more about this feature.

  • #​11071 8ca7c73 Thanks @​bholmesdev! - Adds two new functions experimental_getActionState() and experimental_withState() to support the React 19 useActionState() hook when using Astro Actions. This introduces progressive enhancement when calling an Action with the withState() utility.

    This example calls a like action that accepts a postId and returns the number of likes. Pass this action to the experimental_withState() function to apply progressive enhancement info, and apply to useActionState() to track the result:

    import { actions } from 'astro:actions';
    import { experimental_withState } from '@&#8203;astrojs/react/actions';
    
    export function Like({ postId }: { postId: string }) {
      const [state, action, pending] = useActionState(
        experimental_withState(actions.like),
        0 // initial likes
      );
    
      return (
        <form action={action}>
          <input type="hidden" name="postId" value={postId} />
          <button disabled={pending}>{state} ❤️</button>
        </form>
      );
    }

    You can also access the state stored by useActionState() from your action handler. Call experimental_getActionState() with the API context, and optionally apply a type to the result:

    import { defineAction, z } from 'astro:actions';
    import { experimental_getActionState } from '@&#8203;astrojs/react/actions';
    
    export const server = {
      like: defineAction({
        input: z.object({
          postId: z.string(),
        }),
        handler: async ({ postId }, ctx) => {
          const currentLikes = experimental_getActionState<number>(ctx);
          // write to database
          return currentLikes + 1;
        },
      }),
    };
  • #​11101 a6916e4 Thanks @​linguofeng! - Updates Astro's code for adapters to use the header x-forwarded-for to initialize the clientAddress.

    To take advantage of the new change, integration authors must upgrade the version of Astro in their adapter peerDependencies to 4.9.0.

  • #​11071 8ca7c73 Thanks @​bholmesdev! - Adds compatibility for Astro Actions in the React 19 beta. Actions can be passed to a form action prop directly, and Astro will automatically add metadata for progressive enhancement.

    import { actions } from 'astro:actions';
    
    function Like() {
      return (
        <form action={actions.like}>
          {/* auto-inserts hidden input for progressive enhancement */}
          <button type="submit">Like</button>
        </form>
      );
    }
Patch Changes
  • #​11088 9566fa0 Thanks @​bholmesdev! - Allow actions to be called on the server. This allows you to call actions as utility functions in your Astro frontmatter, endpoints, and server-side UI components.

    Import and call directly from astro:actions as you would for client actions:

v4.8.7

Compare Source

Patch Changes
  • #​11073 f5c8fee Thanks @​matthewp! - Prevent cache content from being left in dist folder

    When contentCollectionsCache is enabled temporary cached content is copied into the outDir for processing. This fixes it so that this content is cleaned out, along with the rest of the temporary build JS.

  • #​11054 f6b171e Thanks @​bholmesdev! - Respect error status when handling Actions with a progressive fallback.

  • #​11092 bfe9c73 Thanks @​duckycoding-dev! - Change slot attribute of IntrinsicAttributes to match the definition of HTMLAttributes's own slot attribute of type string | undefined | null

  • #​10875 b5f95b2 Thanks @​W1M0R! - Fixes a typo in a JSDoc annotation

  • #​11111 a5d79dd Thanks @​bholmesdev! - Fix unexpected headers warning on prerendered routes when using Astro Actions.

  • #​11081 af42e05 Thanks @​V3RON! - Correctly position inspection tooltip in RTL mode

    When RTL mode is turned on, the inspection tooltip tend to overflow the window on the left side.
    Additional check has been added to prevent that.

v4.8.6

Compare Source

Patch Changes

v4.8.5

Compare Source

Patch Changes

v4.8.4

Compare Source

Patch Changes
  • #​11026 8dfb1a2 Thanks @​bluwy! - Skips rendering script tags if it's inlined and empty when experimental.directRenderScript is enabled

  • #​11043 d0d1710 Thanks @​bholmesdev! - Fixes minor type issues in actions component example

  • #​10999 5f353e3 Thanks @​bluwy! - The prefetch feature is updated to better support different browsers and different cache headers setup, including:

    1. All prefetch strategies will now always try to use <link rel="prefetch"> if supported, or will fall back to fetch().
    2. The prefetch() programmatic API's with option is deprecated in favour of an automatic approach that will also try to use <link rel="prefetch> if supported, or will fall back to fetch().

    This change shouldn't affect most sites and should instead make prefetching more effective.

  • #​11041 6cc3fb9 Thanks @​bholmesdev! - Fixes 500 errors when sending empty params or returning an empty response from an action.

  • #​11028 771d1f7 Thanks @​bholmesdev! - Throw on missing server output when using Astro Actions.

  • #​11029 bd34452 Thanks @​bholmesdev! - Actions: include validation error in thrown error message for debugging.

  • #​11046 086694a Thanks @​HiDeoo! - Fixes getViteConfig() type definition to allow passing an inline Astro configuration as second argument

  • #​11026 8dfb1a2 Thanks @​bluwy! - Fixes CSS handling if imported in a script tag in an Astro file when experimental.directRenderScript is enabled

  • #​11020 2e2d6b7 Thanks @​xsynaptic! - Add type declarations for import.meta.env.ASSETS_PREFIX when defined as an object for handling different file types.

  • #​11030 18e7f33 Thanks @​bholmesdev! - Actions: Fix missing message for custom Action errors.

  • #​10981 ad9227c Thanks @​mo! - Adds deprecated HTML attribute "name" to the list of valid attributes. This attribute has been replaced by the global id attribute in recent versions of HTML.

  • #​11013 4ea38e7 Thanks @​QingXia-Ela! - Prevents unhandledrejection error when checking for latest Astro version

  • #​11034 5f2dd45 Thanks @​arganaphang! - Add popovertargetaction to the attribute that can be passed to the button and input element

v4.8.3

Compare Source

Patch Changes

v4.8.2

Compare Source

Patch Changes

v4.8.1

Compare Source

Patch Changes
  • #​10987 05db5f7 Thanks @​ematipico! - Fix a regression where the flag experimental.rewriting was marked mandatory. Is is now optional.

  • #​10975 6b640b3 Thanks @​bluwy! - Passes the scoped style attribute or class to the <picture> element in the <Picture /> component so scoped styling can be applied to the <picture> element

v4.8.0

Compare Source

Minor Changes
  • #​10935 ddd8e49 Thanks @​bluwy! - Exports astro/jsx/rehype.js with utilities to generate an Astro metadata object

  • #​10625 698c2d9 Thanks @​goulvenclech! - Adds the ability for multiple pages to use the same component as an entrypoint when building an Astro integration. This change is purely internal, and aligns the build process with the behaviour in the development server.

  • #​10906 7bbd664 Thanks @​Princesseuh! - Adds a new radio checkbox component to the dev toolbar UI library (astro-dev-toolbar-radio-checkbox)

  • #​10963 61f47a6 Thanks @​delucis! - Adds support for passing an inline Astro configuration object to getViteConfig()

    If you are using getViteConfig() to configure the Vitest test runner, you can now pass a second argument to control how Astro is configured. This makes it possible to configure unit tests with different Astro options when using Vitest’s workspaces feature.

    // vitest.config.ts
    import { getViteConfig } from 'astro/config';
    
    export default getViteConfig(
      /* Vite configuration */
      { test: {} },
      /* Astro configuration */
      {
        site: 'https://example.com',
        trailingSlash: 'never',
      }
    );
  • #​10867 47877a7 Thanks @​ematipico! - Adds experimental rewriting in Astro with a new rewrite() function and the middleware next() function.

    The feature is available via an experimental flag in astro.config.mjs:

    export default defineConfig({
      experimental: {
        rewriting: true,
      },
    });

    When enabled, you can use rewrite() to render another page without changing the URL of the browser in Astro pages and endpoints.

v4.7.1

Compare Source

Patch Changes

v4.7.0

Compare Source

Minor Changes
  • #​10665 7b4f284 Thanks @​Princesseuh! - Adds new utilities to ease the creation of toolbar apps including defineToolbarApp to make it easier to define your toolbar app and app and server helpers for easier communication between the toolbar and the server. These new utilities abstract away some of the boilerplate code that is common in toolbar apps, and lower the barrier of entry for app authors.

    For example, instead of creating an event listener for the app-toggled event and manually typing the value in the callback, you can now use the onAppToggled method. Additionally, communicating with the server does not require knowing any of the Vite APIs anymore, as a new server object is passed to the init function that contains easy to use methods for communicating with the server.

    import { defineToolbarApp } from "astro/toolbar";
    
    export default defineToolbarApp({
      init(canvas, app, server) {
    
    -    app.addEventListener("app-toggled", (e) => {
    -      console.log(`App is now ${state ? "enabled" : "disabled"}`);.
    -    });
    
    +    app.onToggled(({ state }) => {
    +        console.log(`App is now ${state ? "enabled" : "disabled"}`);
    +    });
    
    -    if (import.meta.hot) {
    -      import.meta.hot.send("my-app:my-client-event", { message: "world" });
    -    }
    
    +    server.send("my-app:my-client-event", { message: "world" })
    
    -    if (import.meta.hot) {
    -      import.meta.hot.on("my-server-event", (data: {message: string}) => {
    -        console.log(data.message);
    -      });
    -    }
    
    +    server.on<{ message: string }>("my-server-event", (data) => {
    +      console.log(data.message); // data is typed using the type parameter
    +    });
      },
    })

    Server helpers are also available on the server side, for use in your integrations, through the new toolbar object:

    "astro:server:setup": ({ toolbar }) => {
      toolbar.on<{ message: string }>("my-app:my-client-event", (data) => {
        console.log(data.message);
        toolbar.send("my-server-event", { message: "hello" });
      });
    }

    This is a backwards compatible change and your your existing dev toolbar apps will continue to function. However, we encourage you to build your apps with the new helpers, following the updated Dev Toolbar API documentation.

  • #​10734 6fc4c0e Thanks @​Princesseuh! - Astro will now automatically check for updates when you run the dev server. If a new version is available, a message will appear in the terminal with instructions on how to update. Updates will be checked once per 10 days, and the message will only appear if the project is multiple versions behind the latest release.

    This behavior can be disabled by running astro preferences disable checkUpdates or setting the ASTRO_DISABLE_UPDATE_CHECK environment variable to false.

  • #​10762 43ead8f Thanks @​bholmesdev! - Enables type checking for JavaScript files when using the strictest TS config. This ensures consistency with Astro's other TS configs, and fixes type checking for integrations like Astro DB when using an astro.config.mjs.

    If you are currently using the strictest preset and would like to still disable .js files, set allowJS: false in your tsconfig.json.

Patch Changes

[v4.6.4](https://github.com/withastro


Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

Copy link

stackblitz bot commented May 12, 2024

Review PR in StackBlitz Codeflow Run & review this pull request in StackBlitz Codeflow.

@renovate renovate bot force-pushed the renovate/astro-monorepo branch 23 times, most recently from f200959 to a713971 Compare May 19, 2024 07:21
@renovate renovate bot force-pushed the renovate/astro-monorepo branch 6 times, most recently from bea991a to cc24fe5 Compare May 22, 2024 11:51
@renovate renovate bot force-pushed the renovate/astro-monorepo branch 25 times, most recently from 1792a6d to f13f97c Compare June 20, 2024 06:30
@renovate renovate bot force-pushed the renovate/astro-monorepo branch from f13f97c to f5d1f24 Compare June 20, 2024 10:41
@renovate renovate bot changed the title fix(deps): update astro monorepo fix(deps): update astro monorepo - autoclosed Jun 20, 2024
@renovate renovate bot closed this Jun 20, 2024
@renovate renovate bot deleted the renovate/astro-monorepo branch June 20, 2024 10:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants