Skip to content

chore: Update version for release (pre) #8217

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Dec 5, 2023
Merged

chore: Update version for release (pre) #8217

merged 1 commit into from
Dec 5, 2023

Conversation

@github-actions
Copy link
Contributor

@github-actions github-actions bot commented Dec 5, 2023

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.

⚠️⚠️⚠️⚠️⚠️⚠️

release-next is currently in pre mode so this branch has prereleases rather than normal releases. If you want to exit prereleases, run changeset pre exit on release-next.

⚠️⚠️⚠️⚠️⚠️⚠️

Releases

@remix-run/[email protected]

Minor Changes

  • Deprecate DataFunctionArgs in favor of LoaderFunctionArgs/ActionFunctionArgs. This is aimed at keeping the types aligned across server/client loaders/actions now that clientLoader/clientActon functions have serverLoader/serverAction parameters which differentiate ClientLoaderFunctionArgs/ClientActionFunctionArgs. (#8173)

Patch Changes

@remix-run/[email protected]

Minor Changes

  • Deprecate DataFunctionArgs in favor of LoaderFunctionArgs/ActionFunctionArgs. This is aimed at keeping the types aligned across server/client loaders/actions now that clientLoader/clientActon functions have serverLoader/serverAction parameters which differentiate ClientLoaderFunctionArgs/ClientActionFunctionArgs. (#8173)

Patch Changes

@remix-run/[email protected]

Minor Changes

  • Vite: exclude modules within .server directories from client build (#8154)

  • Add support for clientLoader/clientAction/HydrateFallback route exports (RFC). (#8173)

    Remix now supports loaders/actions that run on the client (in addition to, or instead of the loader/action that runs on the server). While we still recommend server loaders/actions for the majority of your data needs in a Remix app - these provide some levers you can pull for more advanced use-cases such as:

    • Leveraging a data source local to the browser (i.e., localStorage)
    • Managing a client-side cache of server data (like IndexedDB)
    • Bypassing the Remix server in a BFF setup nd hitting your API directly from the browser
    • Migrating a React Router SPA to a Remix application

    By default, clientLoader will not run on hydration, and will only run on subsequent client side navigations.

    If you wish to run your client loader on hydration, you can set clientLoader.hydrate=true to force Remix to execute it on initial page load. Keep in mind that Remix will still SSR your route component so you should ensure that there is no new required data being added by your clientLoader.

    If your clientLoader neds to run on hydration and adds data you require to render the route component, you can export a HydrateFallback component that will render during SSR, and then your route component will not render until the clientLoader has executed on hydration.

    clientAction1 is simpler than clientLoader because it has no hydration use-cases. clientAction will only run on client-side navigations.

    For more information, please refer to the clientLoader and clientAction documentation.

  • Vite: Strict route exports (#8171)

    With Vite, Remix gets stricter about which exports are allowed from your route modules.
    Previously, the Remix compiler would allow any export from routes.
    While this was convenient, it was also a common source of bugs that were hard to track down because they only surfaced at runtime.

    For more, see https://remix.run/docs/en/main/future/vite#strict-route-exports

  • Add a new future.v3_relativeSplatPath flag to implement a breaking bug fix to relative routing when inside a splat route. For more information, please see the React Router 6.21.0 Release Notes and the useResolvedPath docs. (#8216)

Patch Changes

  • Upgrade Vite peer dependency range to v5 (#8172)

  • Support HMR for routes with handle export in Vite dev (#8022)

  • Fix flash of unstyled content for non-Express custom servers in Vite dev (#8076)

  • Bundle CSS imported in client entry file in Vite plugin (#8143)

  • Change Vite build output paths to fix a conflict between how Vite and the Remix compiler each manage the public directory. (#8077)

    This is a breaking change for projects using the unstable Vite plugin.

    The server is now compiled into build/server rather than build, and the client is now compiled into build/client rather than public.

    For more information on the changes and guidance on how to migrate your project, refer to the updated Remix Vite documentation.

  • Remove undocumented legacyCssImports option from Vite plugin due to issues with ?url imports of CSS files not being processed correctly in Vite (#8096)

  • Vite: fix access to default entry.{client,server}.tsx within pnpm workspace on Windows (#8057)

  • Remove unstable_createViteServer and unstable_loadViteServerBuild which were only minimal wrappers around Vite's createServer and ssrLoadModule functions when using a custom server. (#8120)

    This is a breaking change for projects using the unstable Vite plugin with a custom server.

    Instead, we now provide unstable_viteServerBuildModuleId so that custom servers interact with Vite directly rather than via Remix APIs, for example:

    -import {
-  unstable_createViteServer,
-  unstable_loadViteServerBuild,
-} from "@remix-run/dev";
+import { unstable_viteServerBuildModuleId } from "@remix-run/dev";

    Creating the Vite server in middleware mode:

    const vite =
  process.env.NODE_ENV === "production"
    ? undefined
-    : await unstable_createViteServer();
+    : await import("vite").then(({ createServer }) =>
+        createServer({
+          server: {
+            middlewareMode: true,
+          },
+        })
+      );

    Loading the Vite server build in the request handler:

    app.all(
  "*",
  createRequestHandler({
    build: vite
-      ? () => unstable_loadViteServerBuild(vite)
+      ? () => vite.ssrLoadModule(unstable_viteServerBuildModuleId)
      : await import("./build/server/index.js"),
  })
);

  • Pass request handler errors to vite.ssrFixStacktrace in Vite dev to ensure stack traces correctly map to the original source code (#8066)

  • Vite: Preserve names for exports from .client imports (#8200)

    Unlike .server modules, the main idea is not to prevent code from leaking into the server build
    since the client build is already public. Rather, the goal is to isolate the SSR render from client-only code.
    Routes need to import code from .client modules without compilation failing and then rely on runtime checks
    to determine if the code is running on the server or client.

    Replacing .client modules with empty modules would cause the build to fail as ESM named imports are statically analyzed.
    So instead, we preserve the named export but replace each exported value with an empty object.
    That way, the import is valid at build time and the standard runtime checks can be used to determine if then
    code is running on the server or client.

  • Add @remix-run/node to Vite's optimizeDeps.include array (#8177)

  • Improve Vite plugin performance (#8121)

    • Parallelize detection of route module exports
    • Disable server.preTransformRequests in Vite child compiler since it's only used to process route modules

  • Remove automatic global Node polyfill installation from the built-in Vite dev server and instead allow explicit opt-in. (#8119)

    This is a breaking change for projects using the unstable Vite plugin without a custom server.

    If you're not using a custom server, you should call installGlobals in your Vite config instead.

    import { unstable_vitePlugin as remix } from "@remix-run/dev";
+import { installGlobals } from "@remix-run/node";
import { defineConfig } from "vite";

+installGlobals();

export default defineConfig({
  plugins: [remix()],
});

  • Vite: Errors at build-time when client imports .server default export (#8184)

    Remix already stripped .server file code before ensuring that server code never makes it into the client.
    That results in errors when client code tries to import server code, which is exactly what we want!
    But those errors were happening at runtime for default imports.
    A better experience is to have those errors happen at build-time so that you guarantee that your users won't hit them.

  • Fix request instanceof Request checks when using Vite dev server (#8062)

  • Updated dependencies:

@remix-run/[email protected]

Minor Changes

  • Deprecate DataFunctionArgs in favor of LoaderFunctionArgs/ActionFunctionArgs. This is aimed at keeping the types aligned across server/client loaders/actions now that clientLoader/clientActon functions have serverLoader/serverAction parameters which differentiate ClientLoaderFunctionArgs/ClientActionFunctionArgs. (#8173)

Patch Changes

@remix-run/[email protected]

Minor Changes

  • Add support for clientLoader/clientAction/HydrateFallback route exports (RFC). (#8173)

    Remix now supports loaders/actions that run on the client (in addition to, or instead of the loader/action that runs on the server). While we still recommend server loaders/actions for the majority of your data needs in a Remix app - these provide some levers you can pull for more advanced use-cases such as:

    • Leveraging a data source local to the browser (i.e., localStorage)
    • Managing a client-side cache of server data (like IndexedDB)
    • Bypassing the Remix server in a BFF setup nd hitting your API directly from the browser
    • Migrating a React Router SPA to a Remix application

    By default, clientLoader will not run on hydration, and will only run on subsequent client side navigations.

    If you wish to run your client loader on hydration, you can set clientLoader.hydrate=true to force Remix to execute it on initial page load. Keep in mind that Remix will still SSR your route component so you should ensure that there is no new required data being added by your clientLoader.

    If your clientLoader neds to run on hydration and adds data you require to render the route component, you can export a HydrateFallback component that will render during SSR, and then your route component will not render until the clientLoader has executed on hydration.

    clientAction1 is simpler than clientLoader because it has no hydration use-cases. clientAction will only run on client-side navigations.

    For more information, please refer to the clientLoader and clientAction documentation.

  • Add a new future.v3_relativeSplatPath flag to implement a breaking bug fix to relative routing when inside a splat route. For more information, please see the React Router 6.21.0 Release Notes and the useResolvedPath docs. (#8216)

Patch Changes

@remix-run/[email protected]

Minor Changes

  • Add support for clientLoader/clientAction/HydrateFallback route exports (RFC). (#8173)

    Remix now supports loaders/actions that run on the client (in addition to, or instead of the loader/action that runs on the server). While we still recommend server loaders/actions for the majority of your data needs in a Remix app - these provide some levers you can pull for more advanced use-cases such as:

    • Leveraging a data source local to the browser (i.e., localStorage)
    • Managing a client-side cache of server data (like IndexedDB)
    • Bypassing the Remix server in a BFF setup nd hitting your API directly from the browser
    • Migrating a React Router SPA to a Remix application

    By default, clientLoader will not run on hydration, and will only run on subsequent client side navigations.

    If you wish to run your client loader on hydration, you can set clientLoader.hydrate=true to force Remix to execute it on initial page load. Keep in mind that Remix will still SSR your route component so you should ensure that there is no new required data being added by your clientLoader.

    If your clientLoader neds to run on hydration and adds data you require to render the route component, you can export a HydrateFallback component that will render during SSR, and then your route component will not render until the clientLoader has executed on hydration.

    clientAction1 is simpler than clientLoader because it has no hydration use-cases. clientAction will only run on client-side navigations.

    For more information, please refer to the clientLoader and clientAction documentation.

  • Deprecate DataFunctionArgs in favor of LoaderFunctionArgs/ActionFunctionArgs. This is aimed at keeping the types aligned across server/client loaders/actions now that clientLoader/clientActon functions have serverLoader/serverAction parameters which differentiate ClientLoaderFunctionArgs/ClientActionFunctionArgs. (#8173)

  • Add a new future.v3_relativeSplatPath flag to implement a breaking bug fix to relative routing when inside a splat route. For more information, please see the React Router 6.21.0 Release Notes and the useResolvedPath docs. (#8216)

Patch Changes

  • Fix flash of unstyled content for non-Express custom servers in Vite dev (#8076)
  • Pass request handler errors to vite.ssrFixStacktrace in Vite dev to ensure stack traces correctly map to the original source code (#8066)

@remix-run/[email protected]

Minor Changes

  • Add support for clientLoader/clientAction/HydrateFallback route exports (RFC). (#8173)

    Remix now supports loaders/actions that run on the client (in addition to, or instead of the loader/action that runs on the server). While we still recommend server loaders/actions for the majority of your data needs in a Remix app - these provide some levers you can pull for more advanced use-cases such as:

    • Leveraging a data source local to the browser (i.e., localStorage)
    • Managing a client-side cache of server data (like IndexedDB)
    • Bypassing the Remix server in a BFF setup nd hitting your API directly from the browser
    • Migrating a React Router SPA to a Remix application

    By default, clientLoader will not run on hydration, and will only run on subsequent client side navigations.

    If you wish to run your client loader on hydration, you can set clientLoader.hydrate=true to force Remix to execute it on initial page load. Keep in mind that Remix will still SSR your route component so you should ensure that there is no new required data being added by your clientLoader.

    If your clientLoader neds to run on hydration and adds data you require to render the route component, you can export a HydrateFallback component that will render during SSR, and then your route component will not render until the clientLoader has executed on hydration.

    clientAction1 is simpler than clientLoader because it has no hydration use-cases. clientAction will only run on client-side navigations.

    For more information, please refer to the clientLoader and clientAction documentation.

  • Add a new future.v3_relativeSplatPath flag to implement a breaking bug fix to relative routing when inside a splat route. For more information, please see the React Router 6.21.0 Release Notes and the useResolvedPath docs. (#8216)

Patch Changes

@remix-run/[email protected]

Patch Changes

@remix-run/[email protected]

Patch Changes

@remix-run/[email protected]

Patch Changes

@remix-run/[email protected]

Patch Changes

@remix-run/[email protected]

Patch Changes

[email protected]

[email protected]

remix

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

@remix-run/[email protected]

@remix-run/[email protected]

@brophdawg11 brophdawg11 merged commit 74ea09a into release-next Dec 5, 2023
@brophdawg11 brophdawg11 deleted the changeset-release/release-next branch December 5, 2023 20:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@brophdawg11