一次由 React.lazy 引出的 Rspack Dynamic Import Tree Shaking 排查
从入口文件开始读取源码，比如 src/app.tsx。
解析每个模块的语法，识别 import、export、if、import() 这类结构。
替换编译期常量，比如把 process.env.REACT_APP_ENVIRONMENT 替换成 "production"。
根据模块之间的引用关系建立 module graph，知道哪些模块依赖哪些模块。
做模块级优化，比如分析 export 有没有被使用，也就是常说的 tree shaking。
根据同步引用和异步引用拆分 chunk，import() 通常会变成单独的 async chunk。
进入 minimize / minimizer 阶段，做压缩、常量折叠，以及很多不可达代码删除。
最后把 chunk 输出成 index.js、static/js/async/*.js、source map 等文件。
这几个步骤不是完全割裂的，真实实现里会有穿插和回访。但对理解这次问题来说，先记住一个关键点就够了：如果打包器在解析当前模块时就能判断分支不可达，它可能根本不会收集分支里的 import()；如果 import() 已经被收集成 async chunk，后面再删掉它就更难。
最理想的情况是，打包器在解析当前文件时就能直接看出某个分支永远不会执行：
if ( "production" === "development" ) {
}
这种情况下，分支里的代码一般可以很早被跳过。问题会在条件被封装起来之后变复杂，比如：
import { isDevelopment } from "./environment" ;
if ( isDevelopment) {
}
人可以顺着 environment.ts 看出 isDevelopment 在生产环境是 false，但打包器不一定会在同一个阶段、用同一套信息完成这个跨模块判断。尤其当分支里放的是 import() 时，它不只是普通代码，还会让打包器创建一个新的异步 chunk。这个 chunk 一旦被创建，后面再删除它就比删除普通未使用代码更难。
这篇文章里所有现象基本都围绕这个差异展开：同样是生产环境不可达代码，普通静态引用和 React.lazy(() => import(...)) 在打包器内部走的链路不一样。
Tree Shaking：打包时删除没有被使用的代码。这个名字来自“摇树”，把没用到的叶子摇掉。Dead Code Elimination / DCE：删除永远不会执行的代码，比如 if (false) { ... } 里的分支。它和 tree shaking 经常一起出现，但关注点不完全一样：tree shaking 更偏“有没有被用到”，DCE 更偏“有没有可能执行”。Minimize / Minimizer：生产构建里的压缩优化阶段。Rspack 里对应 optimization.minimize 和 optimization.minimizer 这类配置；很多常量折叠、删除不可达分支、压缩变量名的工作会在这里发生。Static import / regular import：普通的静态导入，比如 import Button from "./Button"。它会在模块加载时就建立依赖关系，通常进入主包或被打包器合并到同步 chunk 里。Dynamic import：动态导入，也就是 import("./Panel")。它返回一个 Promise，打包器通常会为它生成单独的 async chunk，等运行时真正需要时再加载。React.lazy：React 提供的懒加载组件 API，常见写法是 const Panel = lazy(() => import("./Panel"))。这里真正触发代码分割的是里面的 import()，React.lazy 只是把这个 Promise 包装成 React 组件。Chunk：打包产物里的代码块。可以粗略理解成最终浏览器会加载的一个 JS 文件或 JS 文件的一部分。Async chunk：由 import() 这类异步加载关系产生的 chunk。它一般不会和首屏主包一起执行，而是在运行时按需加载。Source map：源码和打包产物之间的映射文件。这里用它辅助判断某个 debug panel 的源码是否还留在最终产物对应的映射里。DefinePlugin：Webpack/Rspack 中用于在编译期替换常量表达式的能力。比如把 process.env.REACT_APP_ENVIRONMENT 替换成 "production"。Parser 阶段：打包器读取并分析单个模块源码的阶段。如果这个阶段已经能判断某个分支不可达，就可能根本不会继续收集分支里的 import()。Module graph：模块之间的依赖关系图，比如 A import 了 B，B 又 import 了 C。Chunk graph：模块被分配到哪些最终 chunk 里的关系图。import() 通常会影响这个阶段，因为它可能引入新的 async chunk。Side effect：模块在“被导入”时就发生的可观察行为，比如修改全局变量、注册事件、直接执行日志或请求。存在副作用时，打包器不能随便删除这个模块。
为了确认问题不是业务代码里的其他因素导致的，我单独搭了一个最小 demo。复现代码大概是这样：
import { lazy, Suspense } from 'react' ;
import RegularEnvironmentObjectDebugPanel from './debug-panel/regular/environment-object' ;
import RegularImportedConstDebugPanel from './debug-panel/regular/imported-const' ;
import RegularInlineEnvDebugPanel from './debug-panel/regular/inline-env' ;
import RegularLocalConstDebugPanel from './debug-panel/regular/local-const' ;
import RegularStaticGetterDebugPanel from './debug-panel/regular/static-getter' ;
import { Environment , RuntimeEnvironment , isDevelopment environment.ts 里是几种常见的封装：
export const isDevelopment =
process. env. REACT_APP_ENVIRONMENT === "development" ;
export const Environment = {
isDevelopment,
} as const ;
export class RuntimeEnvironment {
static get isDevelopment ( ) {
return process. env. REACT_APP_ENVIRONMENT === "development" ;
}
}
生产环境下，REACT_APP_ENVIRONMENT 是 "production"，所以上面这些 debug panel 理论上都不应该进入产物。
用 Rsbuild/Rspack 生产构建，结果是：
直接写 process.env.REACT_APP_ENVIRONMENT === 'development'，lazy chunk 会被删掉。
在同一个模块里声明 const localIsDevelopment = process.env... === 'development'，Rspack 也能删掉 lazy chunk。
但如果这个布尔值来自另一个模块的 import，regular static import 可以被删，lazy async chunk 仍然会生成。
getter 更差一些，因为 RuntimeEnvironment.isDevelopment 对 bundler 来说不是一个简单常量读取，regular 和 lazy 都保留了。
为了对比，我又在同一个项目里加了 Webpack 构建。Webpack 生产构建结果是：
也就是说，在这个 case 上 Rspack 甚至比 Webpack 多优化了一步：Rspack 能处理同模块 const，Webpack 当前配置下没有删掉这个 lazy chunk。
上面的表格不是靠肉眼随便猜的，而是从产物里看出来的。生产构建之后，dist 目录大概会长这样：
dist/
index.html
static/js/
index.js
index.js.map
async/
lazy-debug-panel-imported-const.js
lazy-debug-panel-imported-const.js.map
lazy-debug-panel-environment-object.js
lazy-debug-panel-environment-object.js.map
lazy-debug-panel-static-getter.js
lazy-debug-panel-static-getter.js.map
index.html 是入口 HTML，它会加载主 JS。static/js/index.js 是主包，里面包含应用入口、React runtime、Rspack runtime，以及同步进入主包的模块。static/js/async/*.js 是由 import() 拆出来的异步 chunk。只要某个 lazy-debug-panel-xxx.js 文件存在，就说明对应的 dynamic import 已经进入了 chunk graph，并且最终产出了文件。 async chunk 里的代码通常很小，比如 lazy-debug-panel-imported-const.js 里能看到类似这样的结构：
( self. webpackChunkrsbuild_tree_shaking_repro =
self. webpackChunkrsbuild_tree_shaking_repro || [ ] ) . push ( [
[ 825 ] ,
{
551 ( e, r, _) {
_. r ( r) ;
_. d ( r, { default : ( ) => u } ) ;
function u ( ) {
这段结构的意思是：这个文件不是独立执行整个应用，而是往全局的 chunk 队列里注册一组模块。[825] 是 chunk id，551 是这个 chunk 里的模块 id，里面的 LAZY_IMPORTED_CONST_DEBUG_PANEL_INCLUDED 是我故意放进去的哨兵字符串，用来确认这个 debug panel 的代码确实进了产物。
主包 index.js 里还会有一段 chunk id 到文件名的映射，形态大概是这样：
__webpack_require__. u = ( id ) =>
"static/js/async/" +
{
254 : "lazy-debug-panel-environment-object" ,
603 : "lazy-debug-panel-static-getter" ,
825 : "lazy-debug-panel-imported-const" ,
} [ id] +
".js" ;
再往下看主包，会看到它和 app.tsx 里的几个 lazy 组件一一对应。源码里是这样：
const LazyInlineEnv =
process. env . REACT_APP_ENVIRONMENT === 'development'
? lazy ( ( ) => import ( './debug-panel/lazy/inline-env' ) )
: null ;
const LazyLocalConst = localIsDevelopment
? lazy ( ( ) => import ( './debug-panel/lazy/local-const' ) )
: null ;
const LazyImportedConst = isDevelopment
? lazy 生产产物是压缩过的一整行，直接截取 dist/static/js/index.js 里的相关片段是这样：
var f = ! 1 ,
d = f,
p = ( function ( ) {
function e ( ) {
! ( function ( e, n ) {
if ( ! ( e instanceof n ) )
throw new TypeError ( "Cannot call a class as a function" ) ;
} ) ( this , e) ;
}
这里有一个很关键的点：这个 async chunk 在运行时其实是不可达的。
原因很直接：生产环境里这些条件已经变成了 false。上面这段里 f 是 false，d=f，所以 d 也是 false；g() 也就是 App 组件，children 前三个位置已经是 null,null,null，对应 LazyInlineEnv、LazyLocalConst、LazyImportedConst。m 和 h 虽然还保留了 lazy loader 的形态，但它们分别被 d 和 p.isDevelopment guard 住；d 是 false，p.isDevelopment 的 getter 返回 false，所以三元表达式会走到 null，lazy(...) 这一侧不会执行，里面的 l.e(...) 也不会被调用。
这里的 l.e(...) 就是压缩后的 __webpack_require__.e(...)，也就是运行时发起异步加载 chunk 的入口；它不执行，浏览器就不会请求对应的 lazy-debug-panel-xxx.js。所以 async chunk 文件虽然存在，但从这段产物代码看，它在生产运行时没有可达路径。
所以这里的问题不是“线上会不会执行 debug panel”。它不会执行。真正的问题是：既然这个分支已经不可达，为什么对应的 async chunk 文件还被产出来了？
为了让判断更稳定，我在 demo 里还加了一个简单的分析脚本：
const lazyPackaged = files. includes (
` static/js/async/ ${ testCase. lazyChunk } .js ` ,
) ;
const lazyInMap = sourceMaps. some ( ( content ) =>
content. includes ( "debug-panel/lazy/imported-const.tsx" ) ,
) ;
const regularPackaged = jsFiles. some ( ( content ) =>
content. includes
Lazy packaged：有没有产出对应的 async chunk 文件。Lazy in source map：source map 里还能不能找到 lazy debug panel 的源码路径。Regular packaged：主包或同步 JS 里还能不能找到 regular debug panel 的哨兵字符串。Regular in source map：source map 里还能不能找到 regular debug panel 的源码路径。 这样就能区分两件很容易混淆的事：代码在运行时不可达，不代表打包产物里一定不存在；regular import 被 tree shaking 掉，也不代表 dynamic import 产生的 async chunk 一定会被删掉。
看到产物里 children:[null,null,null,...]，很自然会有一个疑问：既然主包里已经能看出这些 lazy 组件不会渲染，为什么 minimize 阶段没有顺手把对应的 async chunk 文件也删掉？
关键在于：minimize 更擅长处理“当前 JS 文件内部的代码”，而不是重新改写整个 chunk graph。
对主包 index.js 来说，minimizer 可以做很多事：
把 process.env.REACT_APP_ENVIRONMENT === 'development' 折叠成 false。
把确定为 false 的 JSX 分支压成 null 或 false。
删除当前文件里已经不可达的函数、变量和表达式。
压缩变量名，比如把 __webpack_require__ 这类运行时代码压成 l。
但 async chunk 文件不是主包里的一段普通函数体。它已经是 chunk graph 里的一个独立输出单元了：
app.tsx
└─ import("./debug-panel/lazy/imported-const")
└─ AsyncDependenciesBlock
└─ async chunk: lazy-debug-panel-imported-const.js
也就是说，等进入 minimize 时，lazy-debug-panel-imported-const.js 已经不再只是主包 AST 里某个可以直接删掉的表达式，而是一个被 chunk graph 记录下来的异步 chunk 资产。minimizer 可以把主包里的引用代码压到不可达，甚至把某些表达式压成 null，但它通常不会基于“另一个 chunk 的 loader 在主包运行时不可达”这个事实，反向删除已经生成的 chunk。
这件事比删除普通 dead code 更难，原因有几个：
import() 会同时影响 module graph 和 chunk graph，不只是当前模块里的表达式。async chunk 可能被多个地方引用，删除它前要确认所有入口、所有 runtime 下都不可达。
chunk 文件名、runtime chunk loading 映射、source map、preload/prefetch 等信息都可能已经依赖这个 chunk。
条件如果来自跨模块 binding、getter、re-export 或带副作用模块，minimizer 很难只看最终 JS 文本就安全判断它一定不可达。
所以这类优化如果要做，通常需要发生在更早的阶段：parser 阶段直接不要收集这个 import()，或者 chunk graph 优化阶段能证明这个 async block 的 dependency condition 是 inactive。单靠最后的 minimize 阶段，很难把“主包里某个 lazy loader 不会执行”升级成“删除另一个已经产出的 async chunk 文件”。
process.env.REACT_APP_ENVIRONMENT 能不能在编译期变成字符串字面量。条件表达式能不能在 parser 阶段被判断成确定的 true 或 false。
如果 parser 已经看到了 import() 并创建了 async dependency block，后续优化阶段能不能再把这个 async chunk 删掉。
第一件事 Rsbuild 是没问题的。loadEnv({ prefixes: ['REACT_APP_'] }) 会把符合前缀的环境变量变成 publicVars，再通过 source.define 传给 Rspack 的 DefinePlugin。所以：
process. env. REACT_APP_ENVIRONMENT === 'development'
"production" === 'development'
真正的分水岭在第二件事：这个 false 能不能在解析当前模块时就被拿到。
const LazyInlineEnv =
process. env . REACT_APP_ENVIRONMENT === 'development'
? lazy ( ( ) => import ( './debug-panel/lazy/inline-env' ) )
: null ;
Rspack 在解析这个模块时，DefinePlugin 能直接命中完整 identifier：process.env.REACT_APP_ENVIRONMENT。
在 Rspack 源码里，DefinePlugin 的 parser hook 会在 evaluate identifier 时工作：
crates/rspack_plugin_javascript/src/parser_plugin/define_plugin/parser.rs
evaluate_identifier：第 102 行附近
crates/rspack_plugin_javascript/src/parser_plugin/define_plugin/walk_data.rs
with_on_evaluate_identifier：第 263 行附近
DefinePlugin 把 define 的代码片段交给 parser evaluate。于是 process.env.REACT_APP_ENVIRONMENT 在当前表达式里可以被当成 "production"。
crates/rspack_plugin_javascript/src/parser_plugin/const/mod.rs
expression_conditional_operation：第 29 行附近parser.evaluate_expression(&expression.test)：第 34 行附近param.as_bool()：第 35 行附近
let param = parser. evaluate_expression ( & expression. test) ;
if let Some ( bool ) = param. as_bool ( ) {
Some ( bool )
} else {
None
}
然后 walker 会根据这个结果只走确定可达的分支：
crates/rspack_plugin_javascript/src/visitors/dependency/parser/walk.rs
walk_conditional_expression：第 1102 行附近if let Some(result)：第 1108 行附近result ? walk cons : walk alt：第 1109 到 1113 行附近
生产环境下 test 是 false，所以 walker 只会走 : null 这个分支，根本不会进入 lazy(() => import(...)) 那个分支。
这就是 inline env 不生成 async chunk 的根本原因：不是后面把 chunk 删掉了，而是 parser 一开始就没走到这个 import()。
const localIsDevelopment =
process. env . REACT_APP_ENVIRONMENT === 'development' ;
const LazyLocalConst = localIsDevelopment
? lazy ( ( ) => import ( './debug-panel/lazy/local-const' ) )
: null ;
Rspack 能删掉这个 async chunk，是因为它有 inline const 相关能力。源码入口在：
crates/rspack_plugin_javascript/src/parser_plugin/inline_const.rs
pre_declarator：第 85 行附近只处理 top-level const：第 91 到 95 行附近
parser.evaluate_expression(declarator.init)：第 100 行附近to_evaluated_inlinable_value：第 106 行附近tag_const_variable：第 113 行附近
const localIsDevelopment = "production" === "development" ;
这个 top-level const 可以被标记成一个可 inline 的布尔常量。后面条件表达式读取 localIsDevelopment 时，parser 能拿到它的值，于是又回到了上一节的路径：ConstPlugin 判断 test 是 false，walker 只走 null 分支，不创建 dynamic import 的 async block。
这也是为什么这个 case 下 Rspack 比 Webpack 表现更好。至少在当前复现配置里，Webpack 没有在 dynamic import 收集之前把这个同模块 const 条件用于跳过 import() 分支，所以仍然生成了 lazy-debug-panel-local-const.js。
import { isDevelopment } from './environment' ;
const LazyImportedConst = isDevelopment
? lazy ( ( ) => import ( './debug-panel/lazy/imported-const' ) )
: null ;
export const isDevelopment =
process. env. REACT_APP_ENVIRONMENT === "development" ;
但当 Rspack 正在解析 app.tsx 时，isDevelopment 不是一个当前模块里的普通 const，它是一个 ESM imported binding。
这意味着在当前模块 parser 阶段，条件表达式的 test 不是一个可以直接 as_bool() 的本地值。ConstPlugin 没法返回 Some(false)，于是 walker 会进入“不知道条件真假”的分支。
Rspack 的 walker 在条件未知时并不是直接放弃，它会收集 branch guard：
crates/rspack_plugin_javascript/src/visitors/dependency/parser/walk.rs
collect_dependencies_in_branch_guard：第 1115 行附近对 consequent 使用 guard：第 1128 到 1131 行附近
对 alternate 使用反向 guard：第 1135 到 1138 行附近
if condition_is_known {
walk ( known_branch)
} else {
walk ( consequent with guard)
walk ( alternate with ! guard)
}
所以 isDevelopment ? lazy(() => import(...)) : null 里的 lazy 分支仍然会被 walker 走到，只是它会带着一个 branch guard。
一旦 walker 走进 lazy(() => import(...))，import() parser plugin 就会创建 dynamic import 依赖和 async block：
crates/rspack_plugin_javascript/src/parser_plugin/import_parser_plugin.rs
import_call：第 261 行附近创建 ImportDependency：第 417 行附近
创建 AsyncDependenciesBlock：第 435 行附近
parser.add_block(Box::new(block))：第 449 行附近
这一步之后，问题就变了：不是“要不要看见 import()”，而是“已经创建的 async block 能不能在后续优化里判断为 inactive 并跳过”。
Rspack 确实给 ImportDependency 留了 branch guard：
crates/rspack_plugin_javascript/src/dependency/esm/import_dependency.rs
branch_guard 字段：第 33 到 34 行附近set_branch_guard：第 68 行附近get_condition：第 167 行附近
branch guard 会被转换成 dependency condition：
crates/rspack_plugin_javascript/src/dependency/branch_guard.rs
compose_dependency_condition：第 126 行附近如果 guard resolve 成 Some(false)，返回 ConnectionState::Active(false)：第 155 到 166 行附近
甚至它也有专门解析 ESM imported boolean guard 的逻辑：
crates/rspack_plugin_javascript/src/dependency/branch_guard.rs
resolve_esm_imported_boolean_guard：第 273 行附近读取 imported export 的 used name：第 293 到 301 行附近
只有 UsedName::Inlined 才继续：第 301 到 303 行附近
只有 inline value 是 boolean 才返回：第 305 到 307 行附近
但这里有个关键限制：它依赖 imported export 已经被分析成 UsedName::Inlined(Boolean(false))。这个信息来自更全局的 export inline 分析，不是解析 app.tsx 条件表达式时天然就有的。
源码里 InlineExportsPlugin 的注释也说明了它为什么放在 optimize_dependencies 阶段：
crates/rspack_plugin_javascript/src/plugin/inline_exports_plugin.rs
注释：第 102 到 106 行附近
hook：CompilationOptimizeDependencies 第 107 行附近
注释大意是：inline exports 会影响 side effects optimization，buildChunkGraph 可以根据 dependency condition 判断依赖是否还 active。如果 imported export 被 inline，那么这个 dependency 就可能 inactive，从而不被 buildChunkGraph 处理。
这听起来似乎应该能删 imported const 的 async chunk。但实际复现结果里没有删掉，说明在这个具体场景中，import() 对应的 async block 并没有因为这个 guard 在 chunk graph 阶段被完全跳过。regular static import 可以被消掉，dynamic import 的 async block 仍然被保留并产出 chunk。
我更倾向于把它理解成“当前优化边界”，而不是简单的 bug。
原因是 dynamic import 不只是一个普通表达式，它会改变 module graph 和 chunk graph。对 bundler 来说，删除一个普通 unused export 和删除一个已经建好的 async chunk group，不是同一件事。
inline env 和 local const 是 parser 阶段就能确定不可达，所以它们最干净：import() 从来没有被收集。
imported const 需要跨模块常量传播。如果要在 parser 阶段就跳过分支，就需要当前模块在解析时知道另一个模块 export 的最终值。这会引入更强的全局分析和阶段耦合。
Rspack 已经有 branch guard 和 inline exports 的设计，说明它并不是完全没考虑这个方向。但从复现结果看，这条链路还没有覆盖到“imported boolean guard 下的 dynamic import async chunk 删除”这个场景。
理论上，这类优化是可以继续做的。比如当 exported const 被证明是 side-effect-free 的 boolean literal，且 dynamic import block 只受这个 guard 控制时，chunk graph 阶段可以更积极地把对应 block 判 inactive。但这类优化要非常小心，因为 ESM binding、模块副作用、re-export、runtime、不同 chunk/runtime 下的 used exports 都会让判断变复杂。
这次对比里有一个容易踩坑的点：不能简单说“Webpack 可以处理，Rspack 不可以”。
Webpack 可以处理 inline env。
Webpack 也不能处理 imported const 下的 lazy async chunk。
在当前配置下，Webpack 甚至没有删掉 same-module local const 下的 lazy async chunk。
Rspack 能处理 inline env 和 same-module local const。
所以这次排查反而说明，Rspack 在同模块常量折叠这块做得更激进一些；真正没有覆盖的是跨模块 imported const 到 dynamic import async chunk 的这条路径。
如果目标是“生产环境不要生成 debug panel 的 async chunk”，最稳的写法是把条件直接写在 import() 所在模块的同一个表达式里：
const LazyDebugPanel =
process. env . REACT_APP_ENVIRONMENT === 'development'
? lazy ( ( ) => import ( './debug-panel' ) )
: null ;
在 Rspack 下，同模块 top-level const 也可以：
const isLocalDevelopment =
process. env . REACT_APP_ENVIRONMENT === 'development' ;
const LazyDebugPanel = isLocalDevelopment
? lazy ( ( ) => import ( './debug-panel' ) )
: null ;
import { isDevelopment } from './environment' ;
const LazyDebugPanel = isDevelopment
? lazy ( ( ) => import ( './debug-panel' ) )
: null ;
就不能期待 async chunk 一定被删除。regular static import 可能会被 tree shaking 掉，但 dynamic import 产生的 chunk 仍可能留在产物里。
如果 debug panel 对产物大小很敏感，我会优先使用 inline env 或同模块 local const。封装环境变量当然更好维护，但封装边界最好不要横跨 dynamic import 的可达性判断。
这次现象的核心不是 Rsbuild 没有注入环境变量，也不是 React.lazy 有什么特殊魔法，而是 Rspack 在不同阶段处理的信息不一样：
DefinePlugin 能替换当前模块里直接出现的 process.env.REACT_APP_ENVIRONMENT。ConstPlugin 只能在 test 能 evaluate 成 boolean 时让 walker 跳过不可达分支。InlineConstPlugin 让同模块 top-level const 也能参与这个判断。imported const 需要跨模块 inline export 信息，parser 阶段拿不到确定 boolean，所以 import() 会先被收集成 AsyncDependenciesBlock。
后续优化和 minimize 阶段能清掉 regular code，不代表一定能删除已经进入 chunk graph 的 async chunk。
一句话概括：想让不可达的 dynamic import 不产出 async chunk，最好让 bundler 在解析当前模块时就能判断这个分支不可达。
}
from
'./environment'
;
const localIsDevelopment =
process. env . REACT_APP_ENVIRONMENT === 'development' ;
const LazyInlineEnv =
process. env . REACT_APP_ENVIRONMENT === 'development'
? lazy ( ( ) =>
import (
'./debug-panel/lazy/inline-env'
) ,
)
: null ;
const LazyLocalConst = localIsDevelopment
? lazy ( ( ) =>
import (
'./debug-panel/lazy/local-const'
) ,
)
: null ;
const LazyImportedConst = isDevelopment
? lazy ( ( ) =>
import (
'./debug-panel/lazy/imported-const'
) ,
)
: null ;
const LazyEnvironmentObject = Environment . isDevelopment
? lazy ( ( ) =>
import (
'./debug-panel/lazy/environment-object'
) ,
)
: null ;
const LazyStaticGetter = RuntimeEnvironment . isDevelopment
? lazy ( ( ) =>
import (
'./debug-panel/lazy/static-getter'
) ,
)
: null ;
return
jsx
(
"div"
,
{
children : "LAZY_IMPORTED_CONST_DEBUG_PANEL_INCLUDED" ,
} ) ;
}
} ,
} ,
] ) ;
(
(
)
=>
import
(
'./debug-panel/lazy/imported-const'
)
)
: null ;
const LazyEnvironmentObject = Environment . isDevelopment
? lazy ( ( ) => import ( './debug-panel/lazy/environment-object' ) )
: null ;
const LazyStaticGetter = RuntimeEnvironment . isDevelopment
? lazy ( ( ) => import ( './debug-panel/lazy/static-getter' ) )
: null ;
var
,
;
return (
( n = e) ,
( t = [
{
key : "isDevelopment" ,
get : function ( ) {
return ! 1 ;
} ,
} ,
] ) ,
null && c ( n. prototype , null ) ,
t && c ( n, t) ,
e
) ;
} ) ( ) ,
m = d
? ( 0 , u. lazy ) ( function ( ) {
return l. e ( 254 ) . then ( l. bind ( l, 328 ) ) ;
} )
: null ,
h = p. isDevelopment
? ( 0 , u. lazy ) ( function ( ) {
return l. e ( 603 ) . then ( l. bind ( l, 83 ) ) ;
} )
: null ;
function g ( ) {
return ( 0 , a. jsxs ) ( u. Suspense , {
fallback : null ,
children : [
null ,
null ,
null ,
m && ( 0 , a. jsx ) ( m, { } ) ,
h && ( 0 , a. jsx ) ( h, { } ) ,
! 1 ,
false ,
f,
d && ( 0 , a. jsx ) ( i, { } ) ,
p. isDevelopment && ( 0 , a. jsx ) ( s, { } ) ,
] ,
} ) ;
}
(
"REGULAR_IMPORTED_CONST_DEBUG_PANEL_INCLUDED"
)
,
) ;