|
1 | 1 | # `@remix-run/dev` |
2 | 2 |
|
| 3 | +## 2.4.0 |
| 4 | + |
| 5 | +### Minor Changes |
| 6 | + |
| 7 | +- Vite: exclude modules within `.server` directories from client build ([#8154](https://github.com/remix-run/remix/pull/8154)) |
| 8 | + |
| 9 | +- Add support for `clientLoader`/`clientAction`/`HydrateFallback` route exports ([RFC](https://github.com/remix-run/remix/discussions/7634)) ([#8173](https://github.com/remix-run/remix/pull/8173)) |
| 10 | + |
| 11 | + 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: |
| 12 | + |
| 13 | + - Leveraging a data source local to the browser (i.e., `localStorage`) |
| 14 | + - Managing a client-side cache of server data (like `IndexedDB`) |
| 15 | + - Bypassing the Remix server in a BFF setup and hitting your API directly from the browser |
| 16 | + - Migrating a React Router SPA to a Remix application |
| 17 | + |
| 18 | + By default, `clientLoader` will not run on hydration, and will only run on subsequent client side navigations. |
| 19 | + |
| 20 | + 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`. |
| 21 | + |
| 22 | + If your `clientLoader` needs 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. |
| 23 | + |
| 24 | + `clientAction` is simpler than `clientLoader` because it has no hydration use-cases. `clientAction` will only run on client-side navigations. |
| 25 | + |
| 26 | + For more information, please refer to the [`clientLoader`](https://remix.run/route/client-loader) and [`clientAction`](https://remix.run/route/client-action) documentation. |
| 27 | + |
| 28 | +- Vite: Strict route exports ([#8171](https://github.com/remix-run/remix/pull/8171)) |
| 29 | + |
| 30 | + With Vite, Remix gets stricter about which exports are allowed from your route modules. |
| 31 | + Previously, the Remix compiler would allow any export from routes. |
| 32 | + While this was convenient, it was also a common source of bugs that were hard to track down because they only surfaced at runtime. |
| 33 | + |
| 34 | + For more, see <https://remix.run/docs/en/main/future/vite#strict-route-exports> |
| 35 | + |
| 36 | +- 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](https://github.com/remix-run/react-router/blob/release-next/CHANGELOG.md#futurev7_relativesplatpath) and the [`useResolvedPath` docs](https://remix.run/hooks/use-resolved-path#splat-paths). ([#8216](https://github.com/remix-run/remix/pull/8216)) |
| 37 | + |
| 38 | +### Patch Changes |
| 39 | + |
| 40 | +- Upgrade Vite peer dependency range to v5 ([#8172](https://github.com/remix-run/remix/pull/8172)) |
| 41 | + |
| 42 | +- Support HMR for routes with `handle` export in Vite dev ([#8022](https://github.com/remix-run/remix/pull/8022)) |
| 43 | + |
| 44 | +- Fix flash of unstyled content for non-Express custom servers in Vite dev ([#8076](https://github.com/remix-run/remix/pull/8076)) |
| 45 | + |
| 46 | +- Bundle CSS imported in client entry file in Vite plugin ([#8143](https://github.com/remix-run/remix/pull/8143)) |
| 47 | + |
| 48 | +- Change Vite build output paths to fix a conflict between how Vite and the Remix compiler each manage the `public` directory. ([#8077](https://github.com/remix-run/remix/pull/8077)) |
| 49 | + |
| 50 | + **This is a breaking change for projects using the unstable Vite plugin.** |
| 51 | + |
| 52 | + The server is now compiled into `build/server` rather than `build`, and the client is now compiled into `build/client` rather than `public`. |
| 53 | + |
| 54 | + For more information on the changes and guidance on how to migrate your project, refer to the updated [Remix Vite documentation](https://remix.run/docs/en/main/future/vite). |
| 55 | + |
| 56 | +- Remove undocumented `legacyCssImports` option from Vite plugin due to issues with `?url` imports of CSS files not being processed correctly in Vite ([#8096](https://github.com/remix-run/remix/pull/8096)) |
| 57 | + |
| 58 | +- Vite: fix access to default `entry.{client,server}.tsx` within pnpm workspace on Windows ([#8057](https://github.com/remix-run/remix/pull/8057)) |
| 59 | + |
| 60 | +- Remove `unstable_createViteServer` and `unstable_loadViteServerBuild` which were only minimal wrappers around Vite's `createServer` and `ssrLoadModule` functions when using a custom server. ([#8120](https://github.com/remix-run/remix/pull/8120)) |
| 61 | + |
| 62 | + **This is a breaking change for projects using the unstable Vite plugin with a custom server.** |
| 63 | + |
| 64 | + Instead, we now provide `unstable_viteServerBuildModuleId` so that custom servers interact with Vite directly rather than via Remix APIs, for example: |
| 65 | + |
| 66 | + ```diff |
| 67 | + -import { |
| 68 | + - unstable_createViteServer, |
| 69 | + - unstable_loadViteServerBuild, |
| 70 | + -} from "@remix-run/dev"; |
| 71 | + +import { unstable_viteServerBuildModuleId } from "@remix-run/dev"; |
| 72 | + ``` |
| 73 | + |
| 74 | + Creating the Vite server in middleware mode: |
| 75 | + |
| 76 | + ```diff |
| 77 | + const vite = |
| 78 | + process.env.NODE_ENV === "production" |
| 79 | + ? undefined |
| 80 | + - : await unstable_createViteServer(); |
| 81 | + + : await import("vite").then(({ createServer }) => |
| 82 | + + createServer({ |
| 83 | + + server: { |
| 84 | + + middlewareMode: true, |
| 85 | + + }, |
| 86 | + + }) |
| 87 | + + ); |
| 88 | + ``` |
| 89 | + |
| 90 | + Loading the Vite server build in the request handler: |
| 91 | + |
| 92 | + ```diff |
| 93 | + app.all( |
| 94 | + "*", |
| 95 | + createRequestHandler({ |
| 96 | + build: vite |
| 97 | + - ? () => unstable_loadViteServerBuild(vite) |
| 98 | + + ? () => vite.ssrLoadModule(unstable_viteServerBuildModuleId) |
| 99 | + : await import("./build/server/index.js"), |
| 100 | + }) |
| 101 | + ); |
| 102 | + ``` |
| 103 | + |
| 104 | +- Pass request handler errors to `vite.ssrFixStacktrace` in Vite dev to ensure stack traces correctly map to the original source code ([#8066](https://github.com/remix-run/remix/pull/8066)) |
| 105 | + |
| 106 | +- Vite: Preserve names for exports from .client imports ([#8200](https://github.com/remix-run/remix/pull/8200)) |
| 107 | + |
| 108 | + Unlike `.server` modules, the main idea is not to prevent code from leaking into the server build |
| 109 | + since the client build is already public. Rather, the goal is to isolate the SSR render from client-only code. |
| 110 | + Routes need to import code from `.client` modules without compilation failing and then rely on runtime checks |
| 111 | + to determine if the code is running on the server or client. |
| 112 | + |
| 113 | + Replacing `.client` modules with empty modules would cause the build to fail as ESM named imports are statically analyzed. |
| 114 | + So instead, we preserve the named export but replace each exported value with an empty object. |
| 115 | + That way, the import is valid at build time and the standard runtime checks can be used to determine if then |
| 116 | + code is running on the server or client. |
| 117 | + |
| 118 | +- Add `@remix-run/node` to Vite's `optimizeDeps.include` array ([#8177](https://github.com/remix-run/remix/pull/8177)) |
| 119 | + |
| 120 | +- Improve Vite plugin performance ([#8121](https://github.com/remix-run/remix/pull/8121)) |
| 121 | + |
| 122 | + - Parallelize detection of route module exports |
| 123 | + - Disable `server.preTransformRequests` in Vite child compiler since it's only used to process route modules |
| 124 | + |
| 125 | +- Remove automatic global Node polyfill installation from the built-in Vite dev server and instead allow explicit opt-in. ([#8119](https://github.com/remix-run/remix/pull/8119)) |
| 126 | + |
| 127 | + **This is a breaking change for projects using the unstable Vite plugin without a custom server.** |
| 128 | + |
| 129 | + If you're not using a custom server, you should call `installGlobals` in your Vite config instead. |
| 130 | + |
| 131 | + ```diff |
| 132 | + import { unstable_vitePlugin as remix } from "@remix-run/dev"; |
| 133 | + +import { installGlobals } from "@remix-run/node"; |
| 134 | + import { defineConfig } from "vite"; |
| 135 | + |
| 136 | + +installGlobals(); |
| 137 | + |
| 138 | + export default defineConfig({ |
| 139 | + plugins: [remix()], |
| 140 | + }); |
| 141 | + ``` |
| 142 | + |
| 143 | +- Vite: Errors at build-time when client imports .server default export ([#8184](https://github.com/remix-run/remix/pull/8184)) |
| 144 | + |
| 145 | + Remix already stripped .server file code before ensuring that server code never makes it into the client. |
| 146 | + That results in errors when client code tries to import server code, which is exactly what we want! |
| 147 | + But those errors were happening at runtime for default imports. |
| 148 | + A better experience is to have those errors happen at build-time so that you guarantee that your users won't hit them. |
| 149 | + |
| 150 | +- Fix `request instanceof Request` checks when using Vite dev server ([#8062](https://github.com/remix-run/remix/pull/8062)) |
| 151 | + |
| 152 | +- Updated dependencies: |
| 153 | + |
| 154 | + |
| 155 | + |
3 | 156 | ## 2.3.1 |
4 | 157 |
|
5 | 158 | ### Patch Changes |
|
0 commit comments