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 dependency astro to v4 - autoclosed #12

Closed
wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Dec 5, 2023

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
astro (source) ^2.6.4 -> ^4.0.0 age adoption passing confidence

Release Notes

withastro/astro (astro)

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

Compare Source

Patch Changes
  • #​10846 3294f7a Thanks @​matthewp! - Prevent getCollection breaking in vitest

  • #​10856 30cf82a Thanks @​robertvanhoesel! - Prevents inputs with a name attribute of action or method to break ViewTransitions' form submission

  • #​10833 8d5f3e8 Thanks @​renovate! - Updates esbuild dependency to v0.20. This should not affect projects in most cases.

  • #​10801 204b782 Thanks @​rishi-raj-jain! - Fixes an issue where images in MD required a relative specifier (e.g. ./)

    Now, you can use the standard ![](relative/img.png) syntax in MD files for images colocated in the same folder: no relative specifier required!

    There is no need to update your project; your existing images will still continue to work. However, you may wish to remove any relative specifiers from these MD images as they are no longer necessary:

    - ![A cute dog](./dog.jpg)
    + ![A cute dog](dog.jpg)
    <!-- This dog lives in the same folder as my article! -->
  • #​10841 a2df344 Thanks @​martrapp! - Due to regression on mobile WebKit browsers, reverts a change made for JavaScript animations during view transitions.

v4.6.3

Compare Source

Patch Changes

v4.6.2

Compare Source

Patch Changes

v4.6.1

Compare Source

Patch Changes

v4.6.0

Compare Source

Minor Changes
  • #​10591 39988ef8e2c4c4888543c973e06d9b9939e4ac95 Thanks @​mingjunlu! - Adds a new dev toolbar settings option to change the horizontal placement of the dev toolbar on your screen: bottom left, bottom center, or bottom right.

  • #​10689 683d51a5eecafbbfbfed3910a3f1fbf0b3531b99 Thanks @​ematipico! - Deprecate support for versions of Node.js older than v18.17.1 for Node.js 18, older than v20.0.3 for Node.js 20, and the complete Node.js v19 release line.

    This change is in line with Astro's Node.js support policy.

  • #​10678 2e53b5fff6d292b7acdf8c30a6ecf5e5696846a1 Thanks @​ematipico! - Adds a new experimental security option to prevent Cross-Site Request Forgery (CSRF) attacks. This feature is available only for pages rendered on demand:

    import { defineConfig } from 'astro/config';
    export default defineConfig({
      experimental: {
        security: {
          csrfProtection: {
            origin: 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 experimental "origin" check is executed only for pages rendered on demand, and only for the requests POST, PATCH, DELETEandPUTwith one of the followingcontent-type` headers: 'application/x-www-form-urlencoded', 'multipart/form-data', 'text/plain'.

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

  • #​10193 440681e7b74511a17b152af0fd6e0e4dc4014025 Thanks @​ematipico! - Adds a new i18n routing option manual to allow you to write your own i18n middleware:

    import { defineConfig } from 'astro/config';
    // astro.config.mjs
    export default defineConfig({
      i18n: {
        locales: ['en', 'fr'],
        defaultLocale: 'fr',
        routing: 'manual',
      },
    });

    Adding routing: "manual" to your i18n config disables Astro's own i18n middleware and provides you with helper functions to write your own: redirectToDefaultLocale, notFound, and redirectToFallback:

    // middleware.js
    import { redirectToDefaultLocale } from 'astro:i18n';
    export const onRequest = defineMiddleware(async (context, next) => {
      if (context.url.startsWith('/about')) {
        return next();
      } else {
        return redirectToDefaultLocale(context, 302);
      }
    });

    Also adds a middleware function that manually creates Astro's i18n middleware. This allows you to extend Astro's i18n routing instead of completely replacing it. Run middleware in combination with your own middleware, using the sequence utility to determine the order:

    import { defineMiddleware, sequence } from 'astro:middleware';
    import { middleware } from 'astro:i18n'; // Astro's own i18n routing config
    
    export const userMiddleware = defineMiddleware();
    
    export const onRequest = sequence(
      userMiddleware,
      middleware({
        redirectToDefaultLocale: false,
        prefixDefaultLocale: true,
      })
    );
  • #​10671 9e14a78cb05667af9821948c630786f74680090d Thanks @​fshafiee! - Adds the httpOnly, sameSite, and secure options when deleting a cookie

Patch Changes

v4.5.18

Compare Source

Patch Changes

v4.5.17

Compare Source

Patch Changes

v4.5.16

Compare Source

Patch Changes

v4.5.15

Compare Source

Patch Changes

v4.5.14

Compare Source

Patch Changes

v4.5.13

Compare Source

Patch Changes

v4.5.12

Compare Source

Patch Changes

v4.5.11

Compare Source

Patch Changes

v4.5.10

Compare Source

Patch Changes

v4.5.9

Compare Source

Patch Changes

v4.5.8

Compare Source

Patch Changes

v4.5.7

Compare Source

Patch Changes

v4.5.6

Compare Source

Patch Changes

v4.5.5

Compare Source

Patch Changes

v4.5.4

Compare Source

Patch Changes

v4.5.3

Compare Source

Patch Changes

v4.5.2

Compare Source

Patch Changes

v4.5.1

Compare Source

Patch Changes

v4.5.0

Compare Source

Minor Changes
  • #​10206 dc87214141e7f8406c0fdf6a7f425dad6dea6d3e Thanks @​lilnasy! - Allows middleware to run when a matching page or endpoint is not found. Previously, a pages/404.astro or pages/[...catch-all].astro route had to match to allow middleware. This is now not necessary.

    When a route does not match in SSR deployments, your adapter may show a platform-specific 404 page instead of running Astro's SSR code. In these cases, you may still need to add a 404.astro or fallback route with spread params, or use a routing configuration option if your adapter provides one.

  • #​9960 c081adf998d30419fed97d8fccc11340cdc512e0 Thanks @​StandardGage! - Allows passing any props to the <Code /> component

  • #​10102 e3f02f5fb1cf0dae3c54beb3a4af3dbf3b06abb7 Thanks @​bluwy! - Adds a new experimental.directRenderScript configuration option which provides a more reliable strategy to prevent scripts from being executed in pages where they are not used.

    This replaces the experimental.optimizeHoistedScript flag introduced in v2.10.4 to prevent unused components' scripts from being included in a page unexpectedly. That experimental option no longer exists and must be removed from your configuration, whether or not you enable directRenderScript:

    // astro.config.mjs
    import { defineConfig } from 'astro/config';
    
    export default defineConfig({
    	experimental: {
    -		optimizeHoistedScript: true,
    +		directRenderScript: true
    	}
    });

    With experimental.directRenderScript configured, scripts are now directly rendered as declared in Astro files (including existing features like TypeScript, importing node_modules, and deduplicating scripts). You can also now conditionally render scripts in your Astro file.

    However, this means scripts are no longer hoisted to the <head> and multiple scripts on a page are no longer bundled together. If you enable this option, you should check that all your <script> tags behave as expected.

    This option will be enabled by default in Astro 5.0.

  • #​10130 5a9528741fa98d017b269c7e4f013058028bdc5d Thanks @​bluwy! - Stabilizes markdown.shikiConfig.experimentalThemes as markdown.shikiConfig.themes. No behaviour changes are made to this option.

  • #​10189 1ea0a25b94125e4f6f2ac82b42f638e22d7bdffd Thanks @​peng! - Adds the option to pass an object to build.assetsPrefix. This allows for the use of multiple CDN prefixes based on the target file type.

    When passing an object to build.assetsPrefix, you must also specify a fallback domain to be used for all other file types not specified.

    Specify a file extension as the key (e.g. 'js', 'png') and the URL serving your assets of that file type as the value:

    // astro.config.mjs
    import { defineConfig } from 'astro/config';
    
    export default defineConfig({
      build: {
        assetsPrefix: {
          js: 'https://js.cdn.example.com',
          mjs: 'https://js.cdn.example.com', // if you have .mjs files, you must add a new entry like this
          png: 'https://images.cdn.example.com',
          fallback: 'https://generic.cdn.example.com',
        },
      },
    });
  • #​10252 3307cb34f17159dfd3f03144697040fcaa10e903 Thanks @​Princesseuh! - Adds support for emitting warning and info notifications from dev toolbar apps.

    When using the toggle-notification event, the severity can be specified through detail.level:

    eventTarget.dispatchEvent(
      new CustomEvent('toggle-notification', {
        detail: {
          level: 'warning',
        },
      })
    );
  • #​10186 959ca5f9f86ef2c0a5a23080cc01c25f53d613a9 Thanks @​Princesseuh! - Adds the ability to set colors on all the included UI elements for dev toolbar apps. Previously, only badge and buttons could be customized.

  • #​10136 9cd84bd19b92fb43ae48809f575ee12ebd43ea8f Thanks @​matthewp! - Changes the default behavior of transition:persist to update the props of persisted islands upon navigation. Also adds a new view transitions option transition:persist-props (default: false) to prevent props from updating as needed.

    Islands which have the transition:persist property to keep their state when using the <ViewTransitions /> router will now have their props updated upon navigation. This is useful in cases where the component relies on page-specific props, such as the current page title, which should update upon navigation.

    For example, the component below is set to persist across navigation. This component receives a products props and might have some internal state, such as which filters are applied:

    <ProductListing transition:persist products={products} />

    Upon navigation, this component persists, but the desired products might change, for example if you are visiting a category of products, or you are performing a search.

    Previously the props would not change on navigation, and your island would have to handle updating them externally, such as with API calls.

    With this change the props are now updated, while still preserving state.

    You can override this new default behavior on a per-component basis using transition:persist-props=true to persist both props and state during navigation:

    <ProductListing transition:persist-props="true" products={products} />
  • #​9977 0204b7de37bf626e1b97175b605adbf91d885386 Thanks @​OliverSpeir! - Supports adding the data-astro-rerun attribute on script tags so that they will be re-executed after view transitions

    <script is:inline data-astro-rerun>
      ...
    </script>
  • #​10145 65692fa7b5f4440c644c8cf3dd9bc50103d2c33b Thanks @​alexanderniebuhr! - Adds experimental JSON Schema support for content collections.

    This feature will auto-generate a JSON Schema for content collections of type: 'data' which can be used as the $schema value for TypeScript-style autocompletion/hints in tools like VSCode.

    To enable this feature, add the experimental flag:

    import { defineConfig } from 'astro/config';
    
    export default defineConfig({
    	experimental: {
    +		contentCollectionJsonSchema: true
    	}
    });

    This experimental implementation requires you to manually reference the schema in each data entry file of the collection:

    // src/content/test/entry.json
    {
    +  "$schema": "../../../.astro/collections/test.schema.json",
      "test": "test"
    }

    Alternatively, you can set this in your VSCode json.schemas settings:

    "json.schemas": [
      {
        "fileMatch": [
          "/src/content/test/**"
        ],
        "url": "../../../.astro/collections/test.schema.json"
      }
    ]

    Note that this initial implementation uses a library with known issues for advanced Zod schemas, so you may wish to consult these limitations before enabling the experimental flag.

  • #​10130 5a9528741fa98d017b269c7e4f013058028bdc5d Thanks @​bluwy! - Migrates shikiji to shiki 1.0

  • #​10268 2013e70bce16366781cc12e52823bb257fe460c0 Thanks @​Princesseuh! - Adds support for page mutations to the audits in the dev toolbar. Astro will now rerun the audits whenever elements are added or deleted from the page.

  • #​10217 5c7862a9fe69954f8630538ebb7212cd04b8a810 Thanks @​Princesseuh! - Updates the UI for dev toolbar audits with new information

Patch Changes

v4.4.15

Compare Source

Patch Changes

v4.4.14

Compare Source

Patch Changes

v4.4.13

Compare Source

Patch Changes

v4.4.12

Compare Source

Patch Changes

v4.4.11

Compare Source

Patch Changes

Configuration

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

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

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

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • 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

sweep-ai bot commented Dec 5, 2023

Apply Sweep Rules to your PR?

  • Apply: All new business logic should have corresponding unit tests.
  • Apply: Refactor large functions to be more modular.
  • Apply: Add docstrings to all functions and file headers.

@renovate renovate bot changed the title fix(deps): update dependency astro to v4 fix(deps): update dependency astro to v4 - autoclosed May 1, 2024
@renovate renovate bot closed this May 1, 2024
@renovate renovate bot deleted the renovate/astro-4.x branch May 1, 2024 14:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants