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

chore: Update version for release #9416

Merged
merged 2 commits into from May 10, 2024

Conversation

github-actions[bot]
Copy link
Contributor

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to release-next, this PR will be updated.

Releases

@remix-run/architect@2.9.2

Patch Changes

  • Updated dependencies:
    • @remix-run/node@2.9.2

@remix-run/cloudflare@2.9.2

Patch Changes

  • Typesafety for single-fetch: defineLoader, defineClientLoader, defineAction, defineClientAction (#9372)

    defineLoader and defineAction are helpers for authoring loaders and actions.
    They are identity functions; they don't modify your loader or action at runtime.
    Rather, they exist solely for typesafety by providing types for args and by ensuring valid return types.

    export let loader = defineLoader(({ request }) => {
      //                                ^? Request
      return { a: 1, b: () => 2 };
      //           ^ type error: `b` is not serializable
    });

    Note that defineLoader and defineAction are not technically necessary for defining loaders and actions if you aren't concerned with typesafety:

    // this totally works! and typechecking is happy too!
    export let loader = () => {
      return { a: 1 };
    };

    This means that you can opt-in to defineLoader incrementally, one loader at a time.

    You can return custom responses via the json/defer utilities, but doing so will revert back to the old JSON-based typesafety mechanism:

    let loader1 = () => {
      return { a: 1, b: new Date() };
    };
    function Component() {
      let data1 = useLoaderData<typeof loader1>();
      //  ^? {a: number, b: Date}
    }
    
    let loader2 = () => {
      return json({ a: 1, b: new Date() }); // this opts-out of turbo-stream
    };
    function Component2() {
      let data2 = useLoaderData<typeof loader2>();
      //  ^? JsonifyObject<{a: number, b: Date}> which is really {a: number, b: string}
    }

    You can also continue to return totally custom responses with Response though this continues to be outside of the typesystem since the built-in Response type is not generic

  • Updated dependencies:

    • @remix-run/server-runtime@2.9.2

@remix-run/cloudflare-pages@2.9.2

Patch Changes

  • Updated dependencies:
    • @remix-run/cloudflare@2.9.2

@remix-run/cloudflare-workers@2.9.2

Patch Changes

  • Updated dependencies:
    • @remix-run/cloudflare@2.9.2

@remix-run/deno@2.9.2

Patch Changes

  • Typesafety for single-fetch: defineLoader, defineClientLoader, defineAction, defineClientAction (#9372)

    defineLoader and defineAction are helpers for authoring loaders and actions.
    They are identity functions; they don't modify your loader or action at runtime.
    Rather, they exist solely for typesafety by providing types for args and by ensuring valid return types.

    export let loader = defineLoader(({ request }) => {
      //                                ^? Request
      return { a: 1, b: () => 2 };
      //           ^ type error: `b` is not serializable
    });

    Note that defineLoader and defineAction are not technically necessary for defining loaders and actions if you aren't concerned with typesafety:

    // this totally works! and typechecking is happy too!
    export let loader = () => {
      return { a: 1 };
    };

    This means that you can opt-in to defineLoader incrementally, one loader at a time.

    You can return custom responses via the json/defer utilities, but doing so will revert back to the old JSON-based typesafety mechanism:

    let loader1 = () => {
      return { a: 1, b: new Date() };
    };
    function Component() {
      let data1 = useLoaderData<typeof loader1>();
      //  ^? {a: number, b: Date}
    }
    
    let loader2 = () => {
      return json({ a: 1, b: new Date() }); // this opts-out of turbo-stream
    };
    function Component2() {
      let data2 = useLoaderData<typeof loader2>();
      //  ^? JsonifyObject<{a: number, b: Date}> which is really {a: number, b: string}
    }

    You can also continue to return totally custom responses with Response though this continues to be outside of the typesystem since the built-in Response type is not generic

  • Updated dependencies:

    • @remix-run/server-runtime@2.9.2

@remix-run/dev@2.9.2

Patch Changes

  • Fix dest already exists error when running remix vite:build (#9305)
  • Vite: Fix issue resolving critical CSS during development when route files are located outside of the app directory. (#9194)
  • Remove @remix-run/node from Vite plugin's optimizeDeps.include list since it was unnecessary and resulted in Vite warnings when not depending on this package. (#9287)
  • Clean up redundant ?client-route=1 imports in development (#9395)
  • Ensure Babel config files are not referenced when applying the react-refresh Babel transform within the Remix Vite plugin (#9241)
  • Updated dependencies:
    • @remix-run/server-runtime@2.9.2
    • @remix-run/node@2.9.2

@remix-run/express@2.9.2

Patch Changes

  • Updated dependencies:
    • @remix-run/node@2.9.2

@remix-run/node@2.9.2

Patch Changes

  • Typesafety for single-fetch: defineLoader, defineClientLoader, defineAction, defineClientAction (#9372)

    defineLoader and defineAction are helpers for authoring loaders and actions.
    They are identity functions; they don't modify your loader or action at runtime.
    Rather, they exist solely for typesafety by providing types for args and by ensuring valid return types.

    export let loader = defineLoader(({ request }) => {
      //                                ^? Request
      return { a: 1, b: () => 2 };
      //           ^ type error: `b` is not serializable
    });

    Note that defineLoader and defineAction are not technically necessary for defining loaders and actions if you aren't concerned with typesafety:

    // this totally works! and typechecking is happy too!
    export let loader = () => {
      return { a: 1 };
    };

    This means that you can opt-in to defineLoader incrementally, one loader at a time.

    You can return custom responses via the json/defer utilities, but doing so will revert back to the old JSON-based typesafety mechanism:

    let loader1 = () => {
      return { a: 1, b: new Date() };
    };
    function Component() {
      let data1 = useLoaderData<typeof loader1>();
      //  ^? {a: number, b: Date}
    }
    
    let loader2 = () => {
      return json({ a: 1, b: new Date() }); // this opts-out of turbo-stream
    };
    function Component2() {
      let data2 = useLoaderData<typeof loader2>();
      //  ^? JsonifyObject<{a: number, b: Date}> which is really {a: number, b: string}
    }

    You can also continue to return totally custom responses with Response though this continues to be outside of the typesystem since the built-in Response type is not generic

  • Updated dependencies:

    • @remix-run/server-runtime@2.9.2

@remix-run/react@2.9.2

Patch Changes

  • Add undefined to useActionData type override (#9322)

  • [REMOVE] bump router (#9414)

  • Allow a nonce to be set on single fetch stream transfer inline scripts (#9364)

  • Typesafety for single-fetch: defineLoader, defineClientLoader, defineAction, defineClientAction (#9372)

    defineLoader and defineAction are helpers for authoring loaders and actions.
    They are identity functions; they don't modify your loader or action at runtime.
    Rather, they exist solely for typesafety by providing types for args and by ensuring valid return types.

    export let loader = defineLoader(({ request }) => {
      //                                ^? Request
      return { a: 1, b: () => 2 };
      //           ^ type error: `b` is not serializable
    });

    Note that defineLoader and defineAction are not technically necessary for defining loaders and actions if you aren't concerned with typesafety:

    // this totally works! and typechecking is happy too!
    export let loader = () => {
      return { a: 1 };
    };

    This means that you can opt-in to defineLoader incrementally, one loader at a time.

    You can return custom responses via the json/defer utilities, but doing so will revert back to the old JSON-based typesafety mechanism:

    let loader1 = () => {
      return { a: 1, b: new Date() };
    };
    function Component() {
      let data1 = useLoaderData<typeof loader1>();
      //  ^? {a: number, b: Date}
    }
    
    let loader2 = () => {
      return json({ a: 1, b: new Date() }); // this opts-out of turbo-stream
    };
    function Component2() {
      let data2 = useLoaderData<typeof loader2>();
      //  ^? JsonifyObject<{a: number, b: Date}> which is really {a: number, b: string}
    }

    You can also continue to return totally custom responses with Response though this continues to be outside of the typesystem since the built-in Response type is not generic

  • [REMOVE] Move defineClientLoader/defineClientAction to @remix-run/react package (#9404)

  • Updated dependencies:

    • @remix-run/server-runtime@2.9.2

@remix-run/serve@2.9.2

Patch Changes

  • Updated dependencies:
    • @remix-run/node@2.9.2
    • @remix-run/express@2.9.2

@remix-run/server-runtime@2.9.2

Patch Changes

  • Don't log thrown response stubs via handleError in Single Fetch (#9369)

  • Automatically wrap resource route naked object returns in json() for back-compat in v2 (and log deprecation warning) (#9349)

  • Typesafety for single-fetch: defineLoader, defineClientLoader, defineAction, defineClientAction (#9372)

    defineLoader and defineAction are helpers for authoring loaders and actions.
    They are identity functions; they don't modify your loader or action at runtime.
    Rather, they exist solely for typesafety by providing types for args and by ensuring valid return types.

    export let loader = defineLoader(({ request }) => {
      //                                ^? Request
      return { a: 1, b: () => 2 };
      //           ^ type error: `b` is not serializable
    });

    Note that defineLoader and defineAction are not technically necessary for defining loaders and actions if you aren't concerned with typesafety:

    // this totally works! and typechecking is happy too!
    export let loader = () => {
      return { a: 1 };
    };

    This means that you can opt-in to defineLoader incrementally, one loader at a time.

    You can return custom responses via the json/defer utilities, but doing so will revert back to the old JSON-based typesafety mechanism:

    let loader1 = () => {
      return { a: 1, b: new Date() };
    };
    function Component() {
      let data1 = useLoaderData<typeof loader1>();
      //  ^? {a: number, b: Date}
    }
    
    let loader2 = () => {
      return json({ a: 1, b: new Date() }); // this opts-out of turbo-stream
    };
    function Component2() {
      let data2 = useLoaderData<typeof loader2>();
      //  ^? JsonifyObject<{a: number, b: Date}> which is really {a: number, b: string}
    }

    You can also continue to return totally custom responses with Response though this continues to be outside of the typesystem since the built-in Response type is not generic

  • [REMOVE] Move defineClientLoader/defineClientAction to @remix-run/react package (#9404)

  • Pass response stub to resource route handlers when single fetch is enabled (#9349)

@remix-run/testing@2.9.2

Patch Changes

  • Updated dependencies:
    • @remix-run/react@2.9.2
    • @remix-run/node@2.9.2

create-remix@2.9.2

remix@2.9.2

remix

See the CHANGELOG.md in individual Remix packages for all changes.

@remix-run/css-bundle@2.9.2

@remix-run/eslint-config@2.9.2

@brophdawg11 brophdawg11 merged commit ff06e16 into release-next May 10, 2024
9 checks passed
@brophdawg11 brophdawg11 deleted the changeset-release/release-next branch May 10, 2024 18:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant