JavaScript Import Maps 综合指南，重点介绍强大的“scopes”功能、作用域继承以及现代 Web 开发的模块解析层级结构。
开启 Web 开发的新纪元：深入了解 JavaScript Import Maps 作用域继承
JavaScript 模块的历程漫长而曲折。从早期 Web 的全局命名空间混乱到 Node.js 的 CommonJS 和浏览器的 AMD 等复杂模式，开发人员一直在寻求更好的方式来组织和共享代码。原生 ES Modules (ESM) 的出现标志着一个重要的转变，它将模块系统直接标准化到 JavaScript 语言和浏览器中。
然而，这种新标准给基于浏览器的开发带来了一个重大障碍。我们在 Node.js 中习以为常的简单、优雅的 import 语句，例如 import _ from 'lodash';，会在浏览器中抛出错误。这是因为浏览器不像具有 `node_modules` 算法的 Node.js，它没有原生机制将这些“裸模块说明符”解析为有效的 URL。
多年来，解决方案是强制性的构建步骤。Webpack、Rollup 和 Parcel 等工具会打包我们的代码，将这些裸说明符转换为浏览器可以理解的路径。虽然这些工具功能强大，但它们增加了复杂性、配置开销和较慢的反馈循环到开发过程中。如果有一种原生的、无需构建工具的方法来解决这个问题呢？输入 JavaScript Import Maps。
Import maps 是一种 W3C 标准，它提供了一种原生机制来控制 JavaScript 导入的行为。它们充当查找表，告诉浏览器如何将模块说明符解析为具体的 URL。但它们的功能远不止简单的别名。真正的游戏规则改变者在于一个鲜为人知但功能强大的特性：`scopes`。Scopes 允许上下文模块解析，使应用程序的不同部分可以导入相同的说明符，但将其解析为不同的模块。这为微前端、A/B 测试和复杂的依赖管理开辟了新的架构可能性，而无需编写一行打包器配置。
本综合指南将带您深入了解 import maps 的世界，特别关注解开由 `scopes` 管理的模块解析层级结构的神秘面纱。我们将探讨作用域继承（或者，更准确地说，是回退机制）的工作原理，剖析解析算法，并揭示实际模式，从而彻底改变您的现代 Web 开发工作流程。
什么是 JavaScript Import Maps？基础概述
从本质上讲，import map 是一个 JSON 对象，它提供了开发人员想要导入的模块的名称与相应模块文件的 URL 之间的映射。它允许您在代码中使用干净的裸模块说明符，就像在 Node.js 环境中一样，并让浏览器处理解析。
基本语法
您可以使用带有属性 type="importmap" 的 <script> 标签来声明 import map。此标签必须放置在 HTML 文档中，在任何使用映射导入的 <script type="module"> 标签之前。
这是一个简单的例子：
<!DOCTYPE html>
<html>
<head>
<!-- The Import Map -->
<script type="importmap">
{
"imports": {
"moment": "https://cdn.skypack.dev/moment",
"lodash": "/js/vendor/lodash-4.17.21.min.js",
"app/": "/js/app/"
}
}
</script>
<!-- Your Application Code -->
<script type="module" src="/js/main.js"></script>
</head>
<body>
<h1>Welcome to Import Maps!</h1>
</body>
</html>
在我们的 /js/main.js 文件中，我们现在可以编写如下代码：
// This works because "moment" is mapped in the import map.
import moment from 'moment';
// This works because "lodash" is mapped.
import { debounce } from 'lodash';
// This is a package-like import for your own code.
// It resolves to /js/app/utils.js because of the "app/" mapping.
import { helper } from 'app/utils.js';
console.log('Today is:', moment().format('MMMM Do YYYY'));
让我们分解 `imports` 对象：
"moment": "https://cdn.skypack.dev/moment"：这是一个直接映射。每当浏览器看到import ... from 'moment'时，它将从指定的 CDN URL 获取模块。"lodash": "/js/vendor/lodash-4.17.21.min.js"：这会将 `lodash` 说明符映射到本地托管的文件。"app/": "/js/app/"：这是一个基于路径的映射。请注意键和值上的尾部斜杠。这告诉浏览器，任何以 `app/` 开头的导入说明符都应相对于 `/js/app/` 进行解析。例如，`import ... from 'app/auth/user.js'` 将解析为 `/js/app/auth/user.js`。这对于在不使用像 `../../` 这样的混乱的相对路径的情况下构建您自己的应用程序代码非常有用。
核心优势
即使使用这种简单的用法，优点也很明显：
- 无构建开发：您可以编写现代的、模块化的 JavaScript，并在浏览器中直接运行它，而无需打包器。这可以加快刷新速度并简化开发设置。
- 解耦的依赖项：您的应用程序代码引用抽象说明符（`'moment'`）而不是硬编码的 URL。这使得仅通过更改 import map JSON 就可以轻松地交换版本、CDN 提供程序或从本地文件移动到 CDN。
- 改进的缓存：由于模块作为单独的文件加载，浏览器可以独立缓存它们。对一个小模块的更改不需要重新下载一个巨大的包。
超越基础：引入 `scopes` 以实现精细控制
顶级的 `imports` 键为您的整个应用程序提供了一个全局映射。但是当您的应用程序的复杂性增加时会发生什么？考虑一个场景，您正在构建一个大型 Web 应用程序，该应用程序集成了第三方聊天小部件。主应用程序使用 charting 库的 5 版本，但旧的聊天小部件仅与 4 版本兼容。
如果没有 `scopes`，您将面临一个艰难的选择：尝试重构小部件，找到另一个小部件，或者接受您无法使用更新的 charting 库。这正是 `scopes` 旨在解决的问题。
import map 中的 `scopes` 键允许您根据导入的位置为同一说明符定义不同的映射。它提供了上下文或作用域的模块解析。
`scopes` 的结构
`scopes` 值是一个对象，其中每个键都是一个 URL 前缀，表示一个“作用域路径”。每个作用域路径的值是一个类似于 `imports` 的对象，它定义了专门在该作用域内应用的映射。
让我们用一个例子来解决我们的 charting 库问题：
<script type="importmap">
{
"imports": {
"charting-lib": "/libs/charting-lib/v5/main.js",
"api-client": "/js/api/v2/client.js"
},
"scopes": {
"/widgets/chat/": {
"charting-lib": "/libs/charting-lib/v4/legacy.js"
}
}
}
</script>
<script type="module" src="/js/app.js"></script>
<script type="module" src="/widgets/chat/init.js"></script>
以下是浏览器如何解释这一点：
- 位于 `/js/app.js` 的脚本想要导入 `charting-lib`。浏览器检查脚本的路径 (`/js/app.js`) 是否与任何作用域路径匹配。它与 `/widgets/chat/` 不匹配。因此，浏览器使用顶级的 `imports` 映射，并且 `charting-lib` 解析为 `/libs/charting-lib/v5/main.js`。
- 位于 `/widgets/chat/init.js` 的脚本也想要导入 `charting-lib`。浏览器看到此脚本的路径 (`/widgets/chat/init.js`) 属于 `/widgets/chat/` 作用域。它在此作用域内查找 `charting-lib` 映射并找到一个。因此，对于此脚本和它从该路径内导入的任何模块，`charting-lib` 解析为 `/libs/charting-lib/v4/legacy.js`。
使用 `scopes`，我们已成功允许应用程序的两个部分使用同一依赖项的不同版本，在没有冲突的情况下和平共存。这是以前只能通过复杂的打包器配置或基于 iframe 的隔离才能实现的控制级别。
核心概念：了解作用域继承和模块解析层级结构
现在我们来谈谈问题的核心。当多个作用域可能匹配文件的路径时，浏览器如何决定使用哪个作用域？并且顶级的 `imports` 中的映射会发生什么？这由一个清晰且可预测的层级结构管理。
黄金法则：最具体的作用域获胜
作用域解析的基本原则是特异性。当某个 URL 上的模块请求另一个模块时，浏览器会查看 `scopes` 对象中的所有键。它会找到作为请求模块的 URL 前缀的最长键。此“最具体”的匹配作用域是唯一一个将用于解析导入的作用域。对于此特定解析，将忽略所有其他作用域。
让我们用一个更复杂的文件结构和 import map 来说明这一点。
文件结构：
- `/index.html`（包含 import map）
- `/js/main.js`
- `/js/feature-a/index.js`
- `/js/feature-a/core/logic.js`
`index.html` 中的 Import Map：
{
"imports": {
"api": "/js/api/v1/api.js",
"ui-kit": "/js/ui/v2/kit.js"
},
"scopes": {
"/js/feature-a/": {
"api": "/js/api/v2-beta/api.js"
},
"/js/feature-a/core/": {
"api": "/js/api/v3-experimental/api.js",
"ui-kit": "/js/ui/v1/legacy-kit.js"
}
}
}
现在让我们从不同的文件跟踪 `import api from 'api';` 和 `import ui from 'ui-kit';` 的解析：
-
在 `/js/main.js` 中：
- 路径 `/js/main.js` 与 `/js/feature-a/` 或 `/js/feature-a/core/` 不匹配。
- 没有作用域匹配。解析回退到顶级的 `imports`。
- `api` 解析为 `/js/api/v1/api.js`。
- `ui-kit` 解析为 `/js/ui/v2/kit.js`。
-
在 `/js/feature-a/index.js` 中：
- 路径 `/js/feature-a/index.js` 以 `/js/feature-a/` 为前缀。它不以 `/js/feature-a/core/` 为前缀。
- 最具体的匹配作用域是 `/js/feature-a/`。
- 此作用域包含 `api` 的映射。因此，`api` 解析为 `/js/api/v2-beta/api.js`。
- 此作用域不包含 `ui-kit` 的映射。此说明符的解析回退到顶级的 `imports`。`ui-kit` 解析为 `/js/ui/v2/kit.js`。
-
在 `/js/feature-a/core/logic.js` 中：
- 路径 `/js/feature-a/core/logic.js` 以 `/js/feature-a/` 和 `/js/feature-a/core/` 为前缀。
- 由于 `/js/feature-a/core/` 更长，因此更具体，因此它被选为获胜的作用域。`/js/feature-a/` 作用域对于此文件完全被忽略。
- 此作用域包含 `api` 的映射。`api` 解析为 `/js/api/v3-experimental/api.js`。
- 此作用域还包含 `ui-kit` 的映射。`ui-kit` 解析为 `/js/ui/v1/legacy-kit.js`。
关于“继承”的真相：它是一种回退，而不是合并
理解一个常见的混淆点至关重要。术语“作用域继承”可能会产生误导。更具体的作用域不继承或合并较不具体（父）作用域。解析过程更简单，更直接：
- 找到导入脚本的 URL 的单个最具体的匹配作用域。
- 如果该作用域包含请求的说明符的映射，请使用它。该过程到此结束。
- 如果获胜的作用域不包含说明符的映射，则浏览器立即检查顶级的 `imports` 对象以查找映射。它不查看任何其他较不具体的作用域。
- 如果在顶级的 `imports` 中找到映射，则使用它。
- 如果在获胜的作用域或顶级的 `imports` 中都找不到映射，则会抛出 `TypeError`。
让我们回顾一下我们的最后一个例子来巩固这一点。从 `/js/feature-a/index.js` 解析 `ui-kit` 时，获胜的作用域是 `/js/feature-a/`。此作用域未定义 `ui-kit`，因此浏览器未检查 `/` 作用域（该作用域不存在作为键）或任何其他父级。它直接转到全局 `imports` 并在那里找到了映射。这是一种回退机制，而不是像 CSS 那样的级联或合并继承。
实际应用和高级场景
作用域 import maps 的强大功能在复杂的实际应用程序中真正闪耀。以下是它们支持的一些架构模式。
微前端
这可以说是 import map 作用域的杀手级用例。想象一个电子商务网站，其中产品搜索、购物车和结帐都是由不同团队开发的单独应用程序（微前端）。它们都集成到一个主机页面中。
- 搜索团队可以使用最新版本的 React。
- 由于遗留依赖项，购物车团队可能正在使用 React 的旧的稳定版本。
- 主机应用程序可能会使用 Preact 作为其外壳以使其轻量级。
import map 可以无缝地协调这一点：
{
"imports": {
"react": "/libs/preact/v10/preact.js",
"react-dom": "/libs/preact/v10/preact-dom.js",
"shared-state": "/js/state-manager.js"
},
"scopes": {
"/apps/search/": {
"react": "/libs/react/v18/react.js",
"react-dom": "/libs/react/v18/react-dom.js"
},
"/apps/cart/": {
"react": "/libs/react/v17/react.js",
"react-dom": "/libs/react/v17/react-dom.js"
}
}
}
在这里，每个微前端（由其 URL 路径标识）都获得其自己隔离的 React 版本。它们仍然可以从顶级的 `imports` 导入 `shared-state` 模块以相互通信。这提供了强大的封装，同时仍然允许受控的互操作性，所有这些都无需复杂的打包器联合设置。
A/B 测试和功能标志
想要为一部分用户测试结帐流程的新版本？您可以为测试组提供一个略有不同的 `index.html`，其中包含修改后的 import map。
控制组的 Import Map：
{
"imports": {
"checkout-flow": "/js/checkout/v1/flow.js"
}
}
测试组的 Import Map：
{
"imports": {
"checkout-flow": "/js/checkout/v2-beta/flow.js"
}
}
您的应用程序代码保持不变：`import start from 'checkout-flow';`。哪个模块被加载的路由完全在 import map 级别处理，该级别可以在服务器上根据用户 cookie 或其他条件动态生成。
管理 Monorepos
在一个大型 monorepo 中，您可能有许多相互依赖的内部包。作用域可以帮助干净地管理这些依赖项。您可以在开发期间将每个包的名称映射到其源代码。
{
"imports": {
"@my-corp/design-system": "/packages/design-system/src/index.js",
"@my-corp/utils": "/packages/utils/src/index.js"
},
"scopes": {
"/packages/design-system/": {
"@my-corp/utils": "/packages/design-system/src/vendor/utils-shim.js"
}
}
}
在此示例中，大多数包都获得了主要的 `utils` 库。但是，`design-system` 包（可能由于特定原因）获得了在其自身作用域内定义的 shimmed 或不同版本的 `utils`。
浏览器支持、工具和部署注意事项
浏览器支持
截至 2023 年底，所有主要的现代浏览器（包括 Chrome、Edge、Safari 和 Firefox）都提供对 import maps 的原生支持。这意味着您可以开始在生产中使用它们，而无需任何 polyfill，从而覆盖了您的绝大多数用户群。
旧版浏览器的回退
对于必须支持缺少原生 import map 支持的旧版应用程序，社区有一个强大的解决方案：`es-module-shims.js` polyfill。当在您的 import map 之前包含此单个脚本时，它会将对 import maps 和其他现代模块功能（如动态 `import()`）的支持移植到旧版环境。它重量轻、经过实战测试，并且是确保广泛兼容性的推荐方法。
<!-- Polyfill for older browsers -->
<script async src="https://ga.jspm.io/npm:es-module-shims@1.8.2/dist/es-module-shims.js"></script>
<!-- Your import map -->
<script type="importmap">
...
</script>
动态的、服务器生成的 Maps
最强大的部署模式之一是根本不在您的 HTML 文件中放置静态 import map。相反，您的服务器可以根据请求动态生成 JSON。这允许：
- 环境切换：在 `development` 环境中提供未缩小的、源映射的模块，并在 `production` 中提供缩小的、生产就绪的模块。
- 基于用户角色的模块：管理员用户可以获得一个 import map，其中包括仅限管理员工具的映射。
- 本地化：根据用户的 `Accept-Language` 标头将 `translations` 模块映射到不同的文件。
最佳实践和潜在的陷阱
与任何强大的工具一样，有一些最佳实践需要遵循，也有一些陷阱需要避免。
- 保持可读性：虽然您可以创建非常深层和复杂的作用域层级结构，但它可能会变得难以调试。努力实现满足您需求的最简单的作用域结构。如果您的 import map JSON 变得复杂，请对其进行注释。
- 始终对路径使用尾部斜杠：映射路径前缀（如目录）时，请确保 import map 中的键和 URL 值都以 `/` 结尾。这对于匹配算法正确处理该目录中的所有文件至关重要。忘记这一点是错误的常见来源。
- 陷阱：非继承陷阱：请记住，特定作用域不继承自较不具体的作用域。它仅回退到全局 `imports`。如果您正在调试解析问题，请始终首先识别单个获胜的作用域。
- 陷阱：缓存 Import Map：您的 import map 是您整个模块图的入口点。如果您更新了 map 中模块的 URL，则需要确保用户获得新的 map。常见的策略是不大量缓存主 `index.html` 文件，或者从包含内容哈希的 URL 动态加载 import map，尽管前者更为常见。
- 调试是您的朋友：现代浏览器开发人员工具非常适合调试模块问题。在“网络”选项卡中，您可以准确地看到为每个模块请求了哪个 URL。在“控制台”中，解析错误将清楚地说明哪个说明符未能从哪个导入脚本解析。
结论：无构建 Web 开发的未来
JavaScript Import Maps，尤其是它们的 `scopes` 特性，代表了前端开发中的范式转变。它们将逻辑的重要部分（模块解析）从预编译构建步骤直接转移到浏览器原生标准中。这不仅仅是为了方便；而是为了构建更灵活、更动态和更具弹性的 Web 应用程序。
我们已经了解了模块解析层级结构的工作原理：最具体的作用域路径始终获胜，并且它回退到全局 `imports` 对象，而不是父作用域。这个简单但强大的规则允许创建复杂的应用程序架构，例如微前端，并以令人惊讶的轻松实现 A/B 测试等动态行为。
随着 Web 平台的不断成熟，对用于开发的繁重、复杂的构建工具的依赖正在减少。Import maps 是这种“无构建”未来的基石，它提供了一种更简单、更快、更标准化的方式来管理依赖项。通过掌握作用域和解析层级结构的概念，您不仅在学习一种新的浏览器 API；您还在装备自己构建下一代全球 Web 应用程序的工具。