OHIF Viewer 浏览器支持指南.browserslistrc 配置、Babel 转译与 Polyfill 策略解析【免费下载链接】ViewersOHIF zero-footprint DICOM viewer and oncology specific Lesion Tracker, plus shared extension packages项目地址: https://gitcode.com/GitHub_Trending/vi/Viewers浏览器兼容性是 Web 医学影像应用zero-footprint DICOM Viewer落地部署时绕不开的一环。本文以 OHIF Viewer 官方文档中的浏览器支持说明为核心结合仓库内真实的.browserslistrc、Babel 配置与 polyfill 相关源码系统讲解 OHIF 支持哪些浏览器、如何通过转译与 polyfill 弥合新旧浏览器差异以及项目为何把开发重心放在现代 evergreen常青浏览器上。读完本文你将能够理解并自定义 OHIF 的浏览器支持矩阵并学会为自己的部署环境配置转译与 polyfill 方案。浏览器支持的核心事实.browserslistrc 说了算OHIF 支持的浏览器并非写死在代码里而是由platform/app项目下的.browserslistrc文件统一声明。文档原文明确指出The browsers that we support are specified in the.browserslistrcfile located in theplatform/appproject.在编写代码时OHIF 会尽量使用最新的语言特性但不会要求运行环境原生支持这些特性——而是依赖babel将代码**转译transpile**成目标浏览器能够执行的语法。也就是说「支持哪些浏览器」与「代码如何被转译」这两件事是前后衔接的前者定义目标后者负责抵达目标。当前仓库中实际存在两份.browserslistrc位于 .browserslistrc仓库根目录和 platform/app/.browserslistrc。它们的职责与内容略有差异仓库根目录的 .browserslistrc# Browsers that we support 1% IE 11 not dead not op_mini all逐行解读这条 browserslist 查询表达式查询含义 1%全球使用份额超过 1% 的浏览器版本IE 11显式将 IE 11 纳入支持范围即使其份额低于阈值not dead排除官方已停止维护 24 个月以上的浏览器如 IE 10 及更早版本not op_mini all排除 Opera Mini 全系列其渲染引擎与标准浏览器差异过大无法用常规转译解决platform/app 下的 .browserslistrc# Browsers that we support 1% IE 11 not IE 11 not dead not op_mini all这份文件与根目录版本的区别在于多了一行not IE 11。它的语义是「排除 IE 11 之前的版本」与显式声明IE 11组合后等价于把支持范围精确收敛为IE 11 及 IE 11 之后的所有达标版本。这进一步印证了文档中的口径OHIF 在旧浏览器上的支持底线是 IE 11。这两份.browserslistrc会被 Babel、Autoprefixer、postcss 等工具链自动读取作为生成目标代码的统一依据。如果你在部署时发现 CSS 前缀或 JS 语法与目标环境不符第一件事就是检查这份文件。In Practice官方支持矩阵与开发优先级根据文档的 In Practice 一节OHIF Viewer 理论上能够运行在以下浏览器上IE 11FirefoxChromeSafariEdge但文档同时非常坦诚地给出了一个关键限制项目并没有足够的资源在所有浏览器上做充分的测试与无缺陷维护。为了推动 Web 医学影像技术向前发展OHIF 将开发精力聚焦在现代 evergreen 浏览器的最新版本上。「对旧浏览器的支持」在 OHIF 语境下被明确定义为两层含义愿意评审针对旧浏览器 bug 修复的 PR在尽可能的情况下让转译目标覆盖旧浏览器的最低 JS 支持水平即.browserslistrc中保留 IE 11 等条目。这意味着如果你运行在旧浏览器上遇到问题官方会接受修复补丁但不会把旧浏览器的体验作为版本发布的阻塞项。这一策略对医学影像这类强监管、强兼容需求的场景尤其值得借鉴——它既没有彻底抛弃存量环境也避免被历史包袱拖住新特性的演进速度。一个值得注意的旁证文档站自身的 browserslist作为对照OHIF 文档站platform/docs在自己的 platform/docs/package.json 中维护了一份独立的 browserslist分为生产与开发两套目标browserslist: { production: [ 0.5%, not dead, not op_mini all ], development: [ last 1 chrome version, last 1 firefox version, last 1 safari version ] }可以看到文档站的生产环境将门槛放宽到0.5%且不再包含 IE 11而开发环境只追求「每个主流浏览器的最近 1 个版本」。这种「不同产物不同目标」的写法展示了 browserslist 的实际用法支持矩阵不是全局一刀切而是可以按项目、按环境分别定制。转译TranspileBabel 如何把新语法带到旧浏览器browserslist 只是声明「要去哪」真正执行转译的是 Babel。OHIF 仓库根目录的 babel.config.js 是整个 monorepo 的 Babel 统一配置platform/app下的 platform/app/babel.config.js 只有一行module.exports require(../../babel.config.js);即直接复用根配置。预设presets与插件pluginsmodule.exports { babelrcRoots: [./platform/*, ./extensions/*, ./modes/*], presets: [babel/preset-env, babel/preset-react, babel/preset-typescript], plugins: [ [babel/plugin-transform-class-properties, { loose: true }], babel/plugin-transform-typescript, [babel/plugin-transform-private-property-in-object, { loose: true }], [babel/plugin-transform-private-methods, { loose: true }], babel/plugin-transform-class-static-block, ], ... };几个值得展开的关键点babelrcRoots让platform/*、extensions/*、modes/*下的所有包共享这份根配置保证整个 monorepo平台核心、各类扩展、模式的转译行为一致babel/preset-env这是转译的核心它会读取.browserslistrc自动决定需要转换哪些语法、注入哪些 polyfill无需手动维护转换清单babel/preset-react与babel/preset-typescript分别负责 JSX 与 TypeScript 的转换这意味着 OHIF 代码库中大量.tsx组件如扩展目录中的 Viewport、panels、tools 组件都会统一走同一套转译管线loose: trueclass 属性、私有方法等转换使用宽松模式产物更接近手写 ES5 代码体积更小但会牺牲少量与原生语义的严格一致性这是库作者常用的取舍。生产与开发环境的目标差异配置中env段针对不同环境区分处理其中与浏览器支持最相关的是production与developmentproduction: { presets: [ // WebPack handles ES6 -- Target Syntax [babel/preset-env, { modules: false }], babel/preset-react, babel/preset-typescript, ], ... }modules: false告诉 Babel不要把 ES Module 转成 CommonJS——模块拆分交给 Webpack/Rsbuild 等打包器处理Babel 只负责语法层面的转译。这与文档中「babel 负责把代码转译到目标浏览器」的分工完全一致转译解决「语法太新」polyfill 解决「特性缺失」打包器解决「模块组织」。另外test环境单独指定了targets: { node: current }即单元测试运行在 Node 当前版本上不再面向浏览器——这说明浏览器兼容的转译逻辑只存在于生产/开发构建路径中测试路径刻意绕开了它以换取测试速度与诊断清晰度。Polyfill语法之外的能力补齐文档对 polyfill 给出了一个非常清晰的定位A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively.并给出了经典示例如果你期望Array.prototype.filter存在但目标浏览器还没实现这个语言特性转译只能修正语法层面的差异而「缺失的内置能力」就需要一段临时的实现来补位——这就是 polyfill 存在的意义。转译与 polyfill 的分工可以总结为一张表层面解决的问题手段语法Syntaxconst、箭头函数、class、可选链、解构等新语法Babel 转译babel/preset-env特性FeatureArray.prototype.filter、Promise、Object.assign等尚未实现的内置 APIPolyfill如core-js、es6-shim仓库中的 polyfill 落地证据在 OHIF 仓库中可以找到两处与 polyfill 直接相关的实现痕迹core-js依赖platform/app/package.json声明了core-js: 3.45.1。core-js 是现代 polyfill 的事实标准也是babel/preset-env在useBuiltIns场景下的默认 polyfill 提供者。文档末尾的注释链接指向 core-js 3 与 Babel 集成的说明也印证了这条技术路线。es6-shim遗留文件platform/app/public/es6-shim.min.js 作为静态资源保留在 public 目录中是早期 ES6 polyfill 方案的产物。这类「shim」与 polyfill 是同一概念的不同称呼说明 OHIF 历史上曾采用前置脚本注入的方式来补齐旧浏览器缺失的 ES6 能力。polyfill 服务迁移从 polyfill.io 到替代方案文档记录了一次重要的安全决策We previously used polyfill io, but due to a security vulnerability in the library, its necessary to switch to alternative services.即 OHIF曾经使用 polyfill.io 这类在线 polyfill 服务但因其库存在安全漏洞必须切换到替代服务。这是一个值得所有前端团队警惕的教训在线 polyfill 服务会在运行时动态下发第三方脚本一旦上游被供应链攻击如向脚本中注入恶意代码所有引用它的站点都会受影响。主流做法是改为构建期注入 polyfill即通过babel/preset-env的useBuiltIns: usage或entry把所需 polyfill 打进本地 bundle不再运行时请求第三方 CDN或切换到经过审计的自托管 polyfill 服务部署层面还应配合 Content-Security-Policy 限制可执行的脚本来源参见 platform/app/public/html-templates/index.html 中关于 CSP 由托管头交付、不使用 meta 标签的说明。core-js 3 与 Babel 的未来方向文档注释中引用的 core-js 3 发布说明core-js 3, babel and a look into the future揭示了这条技术演进的脉络core-js 3 将 polyfill 按特性拆分为更细粒度的模块与 Babel 的useBuiltIns配合后可以做到只注入实际用到的 polyfill显著减小最终包体。对医学影像应用而言这同时意味着更快的首屏加载与更小的攻击面。仓库中core-js: 3.45.1的依赖版本正是这一策略的落地。实践建议如何为你的部署调整支持矩阵结合文档与仓库源码给出以下可直接落地的建议按部署环境改写.browserslistrc如果 OHIF 只部署在内网固定浏览器例如医院信息科统一下发的 Chrome可以把根目录与platform/app下的.browserslistrc收窄为last 2 chrome versions之类既能减少转译产物体积又能规避 IE 相关 hack。反过来如果存在大量老旧工作站在使用则需保留IE 11条目并接受性能与功能的折损。确认 polyfill 的注入方式生产构建应确保 polyfill 来自本地 bundle 或自托管资源而非第三方在线服务以规避文档中提及的 polyfill.io 类供应链风险。用测试兜底browserslist 声明的是「目标」真正的保障来自在目标浏览器上的验证。OHIF 的 Playwright 端到端测试体系见 tests 目录下的*.spec.ts如 Length.spec.ts、MPR.spec.ts可作为参考挑选核心交互链路测量、MPR、分割叠加在目标浏览器矩阵上做回归比全面铺开测试更符合 OHIF「聚焦 evergreen」的务实策略。注意 monorepo 的配置继承platform/app的 Babel 配置直接复用根目录配置.browserslistrc也有根目录与 app 两份。修改时务必保持两者口径一致否则会出现「根目录包面向 A 组浏览器、app 面向 B 组浏览器」的割裂。小结OHIF 的浏览器支持策略可以浓缩为三句话用.browserslistrc声明支持矩阵用 Babel 转译语法用 polyfill 补齐能力。在「In Practice」层面它明确表示能够运行于 IE 11、Firefox、Chrome、Safari、Edge但把测试与维护资源集中于现代 evergreen 浏览器旧浏览器的问题通过评审 bug 修复 PR 与最低 JS 支持来兜底。安全方面仓库已经从 polyfill.io 类在线服务转向 core-js 等构建期方案。这套「声明目标—自动转译—按需补齐—聚焦主流」的组合拳既是 OHIF 能在医疗场景下保持技术先进性的原因也是任何 Web 医学影像团队规划兼容性策略时可复用的模板。【免费下载链接】ViewersOHIF zero-footprint DICOM viewer and oncology specific Lesion Tracker, plus shared extension packages项目地址: https://gitcode.com/GitHub_Trending/vi/Viewers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OHIF Viewer 浏览器支持指南：.browserslistrc 配置、Babel 转译与 Polyfill 策略解析
OHIF Viewer 浏览器支持指南.browserslistrc 配置、Babel 转译与 Polyfill 策略解析【免费下载链接】ViewersOHIF zero-footprint DICOM viewer and oncology specific Lesion Tracker, plus shared extension packages项目地址: https://gitcode.com/GitHub_Trending/vi/Viewers浏览器兼容性是 Web 医学影像应用zero-footprint DICOM Viewer落地部署时绕不开的一环。本文以 OHIF Viewer 官方文档中的浏览器支持说明为核心结合仓库内真实的.browserslistrc、Babel 配置与 polyfill 相关源码系统讲解 OHIF 支持哪些浏览器、如何通过转译与 polyfill 弥合新旧浏览器差异以及项目为何把开发重心放在现代 evergreen常青浏览器上。读完本文你将能够理解并自定义 OHIF 的浏览器支持矩阵并学会为自己的部署环境配置转译与 polyfill 方案。浏览器支持的核心事实.browserslistrc 说了算OHIF 支持的浏览器并非写死在代码里而是由platform/app项目下的.browserslistrc文件统一声明。文档原文明确指出The browsers that we support are specified in the.browserslistrcfile located in theplatform/appproject.在编写代码时OHIF 会尽量使用最新的语言特性但不会要求运行环境原生支持这些特性——而是依赖babel将代码**转译transpile**成目标浏览器能够执行的语法。也就是说「支持哪些浏览器」与「代码如何被转译」这两件事是前后衔接的前者定义目标后者负责抵达目标。当前仓库中实际存在两份.browserslistrc位于 .browserslistrc仓库根目录和 platform/app/.browserslistrc。它们的职责与内容略有差异仓库根目录的 .browserslistrc# Browsers that we support 1% IE 11 not dead not op_mini all逐行解读这条 browserslist 查询表达式查询含义 1%全球使用份额超过 1% 的浏览器版本IE 11显式将 IE 11 纳入支持范围即使其份额低于阈值not dead排除官方已停止维护 24 个月以上的浏览器如 IE 10 及更早版本not op_mini all排除 Opera Mini 全系列其渲染引擎与标准浏览器差异过大无法用常规转译解决platform/app 下的 .browserslistrc# Browsers that we support 1% IE 11 not IE 11 not dead not op_mini all这份文件与根目录版本的区别在于多了一行not IE 11。它的语义是「排除 IE 11 之前的版本」与显式声明IE 11组合后等价于把支持范围精确收敛为IE 11 及 IE 11 之后的所有达标版本。这进一步印证了文档中的口径OHIF 在旧浏览器上的支持底线是 IE 11。这两份.browserslistrc会被 Babel、Autoprefixer、postcss 等工具链自动读取作为生成目标代码的统一依据。如果你在部署时发现 CSS 前缀或 JS 语法与目标环境不符第一件事就是检查这份文件。In Practice官方支持矩阵与开发优先级根据文档的 In Practice 一节OHIF Viewer 理论上能够运行在以下浏览器上IE 11FirefoxChromeSafariEdge但文档同时非常坦诚地给出了一个关键限制项目并没有足够的资源在所有浏览器上做充分的测试与无缺陷维护。为了推动 Web 医学影像技术向前发展OHIF 将开发精力聚焦在现代 evergreen 浏览器的最新版本上。「对旧浏览器的支持」在 OHIF 语境下被明确定义为两层含义愿意评审针对旧浏览器 bug 修复的 PR在尽可能的情况下让转译目标覆盖旧浏览器的最低 JS 支持水平即.browserslistrc中保留 IE 11 等条目。这意味着如果你运行在旧浏览器上遇到问题官方会接受修复补丁但不会把旧浏览器的体验作为版本发布的阻塞项。这一策略对医学影像这类强监管、强兼容需求的场景尤其值得借鉴——它既没有彻底抛弃存量环境也避免被历史包袱拖住新特性的演进速度。一个值得注意的旁证文档站自身的 browserslist作为对照OHIF 文档站platform/docs在自己的 platform/docs/package.json 中维护了一份独立的 browserslist分为生产与开发两套目标browserslist: { production: [ 0.5%, not dead, not op_mini all ], development: [ last 1 chrome version, last 1 firefox version, last 1 safari version ] }可以看到文档站的生产环境将门槛放宽到0.5%且不再包含 IE 11而开发环境只追求「每个主流浏览器的最近 1 个版本」。这种「不同产物不同目标」的写法展示了 browserslist 的实际用法支持矩阵不是全局一刀切而是可以按项目、按环境分别定制。转译TranspileBabel 如何把新语法带到旧浏览器browserslist 只是声明「要去哪」真正执行转译的是 Babel。OHIF 仓库根目录的 babel.config.js 是整个 monorepo 的 Babel 统一配置platform/app下的 platform/app/babel.config.js 只有一行module.exports require(../../babel.config.js);即直接复用根配置。预设presets与插件pluginsmodule.exports { babelrcRoots: [./platform/*, ./extensions/*, ./modes/*], presets: [babel/preset-env, babel/preset-react, babel/preset-typescript], plugins: [ [babel/plugin-transform-class-properties, { loose: true }], babel/plugin-transform-typescript, [babel/plugin-transform-private-property-in-object, { loose: true }], [babel/plugin-transform-private-methods, { loose: true }], babel/plugin-transform-class-static-block, ], ... };几个值得展开的关键点babelrcRoots让platform/*、extensions/*、modes/*下的所有包共享这份根配置保证整个 monorepo平台核心、各类扩展、模式的转译行为一致babel/preset-env这是转译的核心它会读取.browserslistrc自动决定需要转换哪些语法、注入哪些 polyfill无需手动维护转换清单babel/preset-react与babel/preset-typescript分别负责 JSX 与 TypeScript 的转换这意味着 OHIF 代码库中大量.tsx组件如扩展目录中的 Viewport、panels、tools 组件都会统一走同一套转译管线loose: trueclass 属性、私有方法等转换使用宽松模式产物更接近手写 ES5 代码体积更小但会牺牲少量与原生语义的严格一致性这是库作者常用的取舍。生产与开发环境的目标差异配置中env段针对不同环境区分处理其中与浏览器支持最相关的是production与developmentproduction: { presets: [ // WebPack handles ES6 -- Target Syntax [babel/preset-env, { modules: false }], babel/preset-react, babel/preset-typescript, ], ... }modules: false告诉 Babel不要把 ES Module 转成 CommonJS——模块拆分交给 Webpack/Rsbuild 等打包器处理Babel 只负责语法层面的转译。这与文档中「babel 负责把代码转译到目标浏览器」的分工完全一致转译解决「语法太新」polyfill 解决「特性缺失」打包器解决「模块组织」。另外test环境单独指定了targets: { node: current }即单元测试运行在 Node 当前版本上不再面向浏览器——这说明浏览器兼容的转译逻辑只存在于生产/开发构建路径中测试路径刻意绕开了它以换取测试速度与诊断清晰度。Polyfill语法之外的能力补齐文档对 polyfill 给出了一个非常清晰的定位A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively.并给出了经典示例如果你期望Array.prototype.filter存在但目标浏览器还没实现这个语言特性转译只能修正语法层面的差异而「缺失的内置能力」就需要一段临时的实现来补位——这就是 polyfill 存在的意义。转译与 polyfill 的分工可以总结为一张表层面解决的问题手段语法Syntaxconst、箭头函数、class、可选链、解构等新语法Babel 转译babel/preset-env特性FeatureArray.prototype.filter、Promise、Object.assign等尚未实现的内置 APIPolyfill如core-js、es6-shim仓库中的 polyfill 落地证据在 OHIF 仓库中可以找到两处与 polyfill 直接相关的实现痕迹core-js依赖platform/app/package.json声明了core-js: 3.45.1。core-js 是现代 polyfill 的事实标准也是babel/preset-env在useBuiltIns场景下的默认 polyfill 提供者。文档末尾的注释链接指向 core-js 3 与 Babel 集成的说明也印证了这条技术路线。es6-shim遗留文件platform/app/public/es6-shim.min.js 作为静态资源保留在 public 目录中是早期 ES6 polyfill 方案的产物。这类「shim」与 polyfill 是同一概念的不同称呼说明 OHIF 历史上曾采用前置脚本注入的方式来补齐旧浏览器缺失的 ES6 能力。polyfill 服务迁移从 polyfill.io 到替代方案文档记录了一次重要的安全决策We previously used polyfill io, but due to a security vulnerability in the library, its necessary to switch to alternative services.即 OHIF曾经使用 polyfill.io 这类在线 polyfill 服务但因其库存在安全漏洞必须切换到替代服务。这是一个值得所有前端团队警惕的教训在线 polyfill 服务会在运行时动态下发第三方脚本一旦上游被供应链攻击如向脚本中注入恶意代码所有引用它的站点都会受影响。主流做法是改为构建期注入 polyfill即通过babel/preset-env的useBuiltIns: usage或entry把所需 polyfill 打进本地 bundle不再运行时请求第三方 CDN或切换到经过审计的自托管 polyfill 服务部署层面还应配合 Content-Security-Policy 限制可执行的脚本来源参见 platform/app/public/html-templates/index.html 中关于 CSP 由托管头交付、不使用 meta 标签的说明。core-js 3 与 Babel 的未来方向文档注释中引用的 core-js 3 发布说明core-js 3, babel and a look into the future揭示了这条技术演进的脉络core-js 3 将 polyfill 按特性拆分为更细粒度的模块与 Babel 的useBuiltIns配合后可以做到只注入实际用到的 polyfill显著减小最终包体。对医学影像应用而言这同时意味着更快的首屏加载与更小的攻击面。仓库中core-js: 3.45.1的依赖版本正是这一策略的落地。实践建议如何为你的部署调整支持矩阵结合文档与仓库源码给出以下可直接落地的建议按部署环境改写.browserslistrc如果 OHIF 只部署在内网固定浏览器例如医院信息科统一下发的 Chrome可以把根目录与platform/app下的.browserslistrc收窄为last 2 chrome versions之类既能减少转译产物体积又能规避 IE 相关 hack。反过来如果存在大量老旧工作站在使用则需保留IE 11条目并接受性能与功能的折损。确认 polyfill 的注入方式生产构建应确保 polyfill 来自本地 bundle 或自托管资源而非第三方在线服务以规避文档中提及的 polyfill.io 类供应链风险。用测试兜底browserslist 声明的是「目标」真正的保障来自在目标浏览器上的验证。OHIF 的 Playwright 端到端测试体系见 tests 目录下的*.spec.ts如 Length.spec.ts、MPR.spec.ts可作为参考挑选核心交互链路测量、MPR、分割叠加在目标浏览器矩阵上做回归比全面铺开测试更符合 OHIF「聚焦 evergreen」的务实策略。注意 monorepo 的配置继承platform/app的 Babel 配置直接复用根目录配置.browserslistrc也有根目录与 app 两份。修改时务必保持两者口径一致否则会出现「根目录包面向 A 组浏览器、app 面向 B 组浏览器」的割裂。小结OHIF 的浏览器支持策略可以浓缩为三句话用.browserslistrc声明支持矩阵用 Babel 转译语法用 polyfill 补齐能力。在「In Practice」层面它明确表示能够运行于 IE 11、Firefox、Chrome、Safari、Edge但把测试与维护资源集中于现代 evergreen 浏览器旧浏览器的问题通过评审 bug 修复 PR 与最低 JS 支持来兜底。安全方面仓库已经从 polyfill.io 类在线服务转向 core-js 等构建期方案。这套「声明目标—自动转译—按需补齐—聚焦主流」的组合拳既是 OHIF 能在医疗场景下保持技术先进性的原因也是任何 Web 医学影像团队规划兼容性策略时可复用的模板。【免费下载链接】ViewersOHIF zero-footprint DICOM viewer and oncology specific Lesion Tracker, plus shared extension packages项目地址: https://gitcode.com/GitHub_Trending/vi/Viewers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考