9 月 16 日，全栈 Web 框架 Remix 正式发布了 2.0 版本，Remix 团队在发布 1.0 版本后经过近 2 年的持续努力，发布了 19 个次要版本、100 多个补丁版本，并解决了数千个问题和拉取请求，终于迎来了第二个主要版本！
Remix 具有以下特性：
- 追求速度、用户体验（UX），支持任何 SSR/SSG 等
- 基于 Web 基础技术，如 HTML/CSS 与 HTTP 以及 Web Fecth API，在绝大部分情况可以不依赖于 JavaScript 运行，所以可以运行在任何环境下，如 Web Browser、Cloudflare Workers、Serverless 或者 Node.js 等
- 客户端与服务端一致的开发体验，客户端代码与服务端代码写在一个文件里，无缝进行数据交互，同时基于 TypeScript，类型定义可以跨客户端与服务端共用
- 内置文件即路由、动态路由、嵌套路由、资源路由等
- 去掉 Loading、骨架屏等任何加载状态，页面中所有资源都可以预加载（Prefetch），页面几乎可以立即加载
- 告别以往瀑布式（Waterfall）的数据获取方式，数据获取在服务端并行（Parallel）获取，生成完整 HTML 文档，类似 React 的并发特性
- 提供开发网页需要所有状态，开箱即用；提供所有需要使用的组件，包括
、、、、，用于处理元信息、脚本、CSS、路由和表单相关的内容- 内置错误处理，针对非预期错误处理的
和开发者抛出错误处理的
Remix 是一个由 React Router 开发团队所开发的基于 React 和 TypeScript 的全栈框架。2021 年 11 月，Remix 正式开源，至今已在 Github 上获得了 24.6k star。Remix 正式开源时，引发了前端圈不小的关注，其被普遍认为是 Next.js 的强劲对手，那时隔两年，它和 Next.js 之间的“竞争”怎么样了呢？
目前，Next.js 拥有 112k star，是 Remix 的近 5 倍。Next.js 周下载量 279 万，而 Remix 仅有 1.4 万，Next.js 是 Remix 的近 200 倍。可见，Remix 并没有像大家预料的那样，成为 Next.js 的有力竞争对手，在开发者社区中只有较小的市场份额。尽管如此，Remix 仍然吸引了一些开发者，并且在特定领域或项目中有其优势和适用性。
下面就来看看 Remix 2.0 都有哪些更新！
v1.0 以来的更新
- v1.8和v1.10中，将 Remix与React Router v6进行了对齐。当开始开发Remix时，承诺它将使React Router变得更好。这个版本真正实现了这一承诺，并将两个库都对齐到使用相同的底层依赖。
- 在v1.11中，发布了"promises over the wire"，即延迟加载模块。现在，如果真的想在Remix应用中添加 loading 图标，可以这么做了！
- 在v1.11中，添加了"flat"路由，简化了使用嵌套布局而不需要嵌套目录的操作，这成为v2版本的默认设置。
- 在v1.13和v1.16中，改进了Remix对各种CSS策略的支持，包括PostCSS、CSS模块、Vanilla Extract 和CSS副作用（全局）导入。
- 在v1.14和v1.18中，发布了一个新的开发服务器，支持热更新（HMR）和热数据重载（HDR）。这个新的开发服务器成为v2版本的默认设置。
- 在v2版本中，最重要的亮点之一是全新的
create-remix命令行工具体验。
v2.0 的更新内容
重大变化
升级的依赖要求
Remix v2已经升级了对React和Node的最低版本支持，并正式支持以下版本：
- React 18
- Node 18 或更高版本
移除未来标志
以下未来标志已被移除，并且它们的行为现在是默认的，现在可以从remix.config.js文件中删除这些设置。
v2_dev，新的开发服务器，具有HMR + HDR，如果在future.v2_dev中有配置而不仅仅是布尔值（例如，future.v2_dev.port），可以将它们提升到remix.config.js中的根dev对象中。v2_errorBoundary，移除了CatchBoundary，改为使用单个ErrorBoundaryv2_headers，修改了嵌套路由场景中的头部逻辑v2_meta，修改了meta()的返回格式v2_normalizeFormMethod，将formMethod规范化为大写v2_routeConvention，现在默认情况下，路由使用扁平化路由约定
重大变更/API 删除
下面列出了 Remix v1 中具有弃用警告的其他重大更改/API 删除。如果使用的是最新1.19.3版本且没有任何控制台警告，那么可能可以继续执行所有这些操作！
（1）有破坏性更改/API移除
- remix.config.js
- 将
browserBuildDirectory重命名为assetsBuildDirectory - 删除
devServerBroadcastDelay - 将
devServerPort重命名为dev.port - 如果在1.x版本中选择此选项，则配置标记将是
future.v2_dev.port，但在稳定的2.x版本中，它将是dev.port - 将默认的
serverModuleFormat从cjs更改为esm - 删除
serverBuildTarget - 将
serverBuildDirectory更改为serverBuildPath - 默认情况下不再在服务器上对Node内置模块进行
polyfill，必须通过serverNodeBuiltinsPolyfill选择加入polyfill
- @remix-run/react
删除
useTransition删除
fetcher.type并压缩fetcher.submissionstate：“loading”，而不是state：“submitting”，以更好地与底层的GET请求保持一致要求
camelCased版本的imagesrcset/imagesizes
（2）没有弃用警告
此版本没能在每个破坏性更改或API移除上都收到废弃警告。以下是可能需要查看的剩余变更列表，以升级到v2：
- remix.config.js
- Node内置模块不再默认在浏览器中进行polyfill，可以通过
browserNodeBuiltinsPolyfill选项选择加入polyfill - 如果存在配置文件，则
PostCSS/Tailwind将默认启用，可以通过postcss和tailwind标志禁用此功能
- @remix-run/cloudflare
删除
createCloudflareKVSessionStorage方法不再支持@cloudflare/workers-types v2和v3
@remix-run/dev
删除
REMIX_DEV_HTTP_ORIGIN，增加REMIX_DEV_ORIGIN删除
REMIX_DEV_SERVER_WS_PORT，增加dev.port或--port删除
--no-restart/restart标志，增加--manual/manual删除
--scheme/scheme和--host/host，增加REMIX_DEV_ORIGIN删除
codemod命令@remix-run/eslint-config
删除
@remix-run/eslint-config/jest配置删除魔法
imports的ESLint警告@remix-run/netlify
@remix-run/netlify适配器已被删除，推荐使用Netlify官方适配器@remix-run/node
默认不再对
fetch进行polyfill，应用需要调用installGlobals()来安装polyfills不再从
@remix-run/node导出fetch和相关 API，应用应使用全局命名空间中的版本应用需要调用
sourceMapSupport.install()来设置源映射支持@remix-run/react
删除
unstable_shouldReload，增加shouldRevalidate@remix-run/serve
如果3000端口被占用且未指定PORT，则
remix-serve将选择一个可用的端口集成手动模式
删除未记录的
createApp Node API在
remix-serve中保留动态imports以供外部bundle使用@remix-run/vercel
@remix-run/vercel适配器已被删除，推荐使用Vercel官方提供的功能create-remix
停止传递
isTypeScript给remix.init脚本remix
删除魔法
exports
（3）破坏类型变化
- 从
future.v2_meta类型中删除了V2_前缀，因为它们现在是默认行为。
V2_MetaArgs->MetaArgsV2_MetaDescriptor->MetaDescriptorV2_MetaFunction->MetaFunctionV2_MetaMatch->MetaMatchV2_MetaMatches->MetaMatchesV2_ServerRuntimeMetaArgs->ServerRuntimeMetaArgsV2_ServerRuntimeMetaDescriptor->ServerRuntimeMetaDescriptorV2_ServerRuntimeMetaFunction->ServerRuntimeMetaFunctionV2_ServerRuntimeMetaMatch->ServerRuntimeMetaMatchV2_ServerRuntimeMetaMatches->ServerRuntimeMetaMatches
- 以下类型已进行调整，更偏向于使用
unknown而不是any，并与底层的React Router类型保持一致： 将
useMatches()的返回类型从RouteMatch改名为UIMatch将
LoaderArgs/ActionArgs改名为LoaderFunctionArgs/ActionFunctionArgs将
AppData的类型从any改为unknown将
Location["state"]（useLocation.state）的类型从any改为unknown将
UIMatch["data"]（useMatches()[i].data）的类型从any改为unknown将
UIMatch["handle"]（useMatches()[i].handle）的类型从{ [k: string]: any }改为unknown将
Fetcher["data"]（useFetcher().data）的类型从any改为unknownMetaMatch.handle（在meta()函数中使用）的类型从any改为unknownAppData/RouteHandle不再导出，因为它们只是unknown的别名
新增功能
- 新的
create-remix命令行界面工具
- 最显著的改变是，不再使用下拉菜单选择模板/堆栈，而是使用
--template参数和不断增长的可用模板列表。 - 新增
--overwrite参数 - 支持
bun包管理器
- 通过
build.mode检测构建模式 - 支持通过
serverNodeBuiltinsPolyfill.globals/browserNodeBuiltinsPolyfill.globals来对Node全局对象进行polyfill - 新的
redirectDocument实用工具，通过重新加载文档实现重定向 - 在
meta参数中添加error，以便可以渲染错误等 unstable_createRemixStub现在支持在stubbed Remix路由上添加meta/links函数unstable_createRemixStub不再支持在路由上使用element/errorElement属性。必须使用Component/ErrorBoundary与从Remix路由模块导出的内容匹配。
其他更新
- Remix现在在内部使用React Router的
route.lazy方法在导航时加载路由模块。 - 删除了
@remix-run/node中的atob/btoapolyfills，改用内置版本。 - 将
@remix-run/dev包与@remix-run/css-bundle包的内容解耦。 - 现在，
@remix-run/css-bundle包的内容完全由Remix编译器管理。尽管仍然建议Remix依赖项共享相同的版本，但这个变化确保在升级@remix-run/dev而不升级@remix-run/css-bundle时没有运行时错误。 remix-serve现在将选择一个空闲的端口（如果3000端口被占用）。
- 如果设置了PORT环境变量，r
emix-serve将使用该端口。 - 否则，
remix-serve将选择一个空闲的端口（除非3000端口已被占用）。
- 更新的依赖项：
react-router-dom@6.16.0@remix-run/router@1.9.0@remix-run/web-fetch@4.4.0@remix-run/web-file@3.1.0@remix-run/web-stream@1.1.0
React Server Components？
Remix 对于 React Server Components（RSC）的支持计划是积极的。他们希望在Remix v3中添加对RSC的支持，并希望能够展示这项技术在多个框架中的能力。
RSC是一个有趣且强大的功能，但是 Remix v2 是基于当前稳定的React特性构建的，因此 RSC 在 Remix v2 中尚未包含。一旦RSC稳定下来，Remix 将会支持它。
然而，与之前支持的其他React特性相比，“支持RSC”需要更深入的集成。RSC的异步组件与Remix的加载器和组件结合得非常相似，并且Remix在v3中决定摒弃使用第三方库useLoaderData，因此在数据加载方面可能会有所不同。他们希望开发者只需要将现有的加载器代码迁移到新的异步组件中，但需要注意数据依赖的瀑布效应。
Remix团队在今年早些时候的Remix Conf上与React核心团队的成员举办了一个讨论会，讨论了RSC以及如何共同推进这项技术的稳定发布。他们以各种方式帮助准备RSC，并希望能够成功地集成它到Remix中。
