NextJs 12.2.2触发Cannot set property window报错解决方案咨询

问题复现场景 #

• 项目从Next.js 12.1.6升级至12.2.2版本，执行npm run dev启动开发服务后，浏览器端负责SplitText效果的第三方库抛出运行错误
• 完整错误信息：

TypeError: Cannot set property window of #<Window> which has only a getter

• 触发错误的库头部UMD兼容代码：

!(function (D, u) {
  "object" == typeof exports && "undefined" != typeof module
    ? u(exports)
    : "function" == typeof define && define.amd
    ? define(["exports"], u)
    : u(((D = D || self).window = D.window || {}));
})(this, function (e) {
// 库核心业务逻辑
...

错误根因 #

这段是早期前端库通用的UMD模块化兼容代码，三个分支分别适配CommonJS环境、AMD环境、浏览器直接引入的全局挂载场景。最后一个分支的本意是：在无模块化的浏览器环境下，把库的导出内容挂载到全局window对象上，(D = D || self).window = D.window || {}的写法是为了给非标准沙箱环境做兜底，当全局window不存在时先创建一个空对象作为window载体。

Next.js 12.2版本调整了开发模式下的浏览器端运行沙箱逻辑，window.window属性被设置为仅可读（只定义了getter访问器，未定义setter写入方法），而上述老UMD代码不会提前判断属性是否可写，直接执行赋值操作，就会触发“给只有getter的属性赋值”的类型错误。

基础概念说明：对象属性如果仅配置getter、未配置setter，该属性为只读状态，任何写入操作都会抛出类型错误。

修复方案 #

按优先级从高到低排列：

• 升级SplitText相关依赖到最新版本
  该兼容问题属于Next.js 12.2升级后的通用问题，绝大多数仍在维护的前端库都已经推送了修复版本，调整了UMD头部的判断逻辑，不会再强行给window.window属性赋值，该方案改动成本最低，优先选用。
• 用next/dynamic动态引入库，关闭SSR
  大部分文字动效类库本身就不支持服务端渲染，引入时可以关闭SSR配置，让库仅在客户端水合完成后加载，避开开发沙箱的属性拦截：

  import dynamic from 'next/dynamic'
  const SplitText = dynamic(() => import('对应splittext库的引入路径'), { ssr: false })
  

• 调整next.config.js配置临时兼容
  如果暂时无法升级依赖、也无法修改引入方式，可以临时关闭React严格模式，绕开开发环境的沙箱属性校验（该方案为临时兼容方案，不推荐长期使用）：

  /** @type {import('next').NextConfig} */
  const nextConfig = {
    reactStrictMode: false,
  }
  module.exports = nextConfig
  

• 手动patch依赖代码
  如果使用的是已经停止维护的旧库，可以直接修改node_modules内对应库的UMD头部逻辑，把强制赋值的逻辑调整为先判断属性存在性、可写性再操作：
  将原代码的u(((D = D || self).window = D.window || {}));替换为：

  D = D || self;
  if (!D.window) D.window = {};
  u(D.window);
  

  修改后可以借助patch-package工具把改动持久化，避免重新安装依赖后修改失效。

内容的提问来源于stack exchange，提问作者York Wang