Document

Hello, Vite with React and TS!

;\n };\n export default App;\n ```\n - Vite 会先将`tsx`文件中的 TypeScript 部分编译成 JavaScript，同时会保留 React 的 JSX 语法。因为现代浏览器虽然不能直接理解 JSX 语法，但是 Vite 会通过`@vitejs/plugin - react`插件等手段来处理 JSX。\n - 这个插件会将 JSX 语法在发送给浏览器之前转换为浏览器能够理解的`React.createElement`函数调用形式（或者其他等价的高效形式，比如使用`jsx - runtime`）。例如，上面的`App.tsx`中的 JSX 部分可能会被转换为类似以下的 JavaScript 代码：\n ```javascript\n import React from \"react\";\n const App = () => {\n return React.createElement(\"div\", null, \"Hello, Vite with React and TS!\");\n };\n export default App;\n ```\n - 这样转换后的代码就可以在浏览器中正常运行，并且能够正确地渲染 React 组件。\n","reactions",{"_54":163,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/1090/reactions","total_count","+1","-1","laugh","hooray","confused","heart","rocket","eyes","timeline_url","https://api.github.com/repos/pro-collection/interview-question/issues/1090/timeline","performed_via_github_app","state_reason","score",1,{"_54":180,"_56":57,"_58":181,"_60":182,"_62":183,"_64":184,"_66":185,"_68":186,"_70":187,"_72":188,"_74":189,"_107":190,"_120":121,"_122":26,"_123":-5,"_124":199,"_126":200,"_148":141,"_142":202,"_144":202,"_147":-5,"_151":152,"_153":203,"_158":-5,"_159":204,"_161":205,"_173":207,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/1089","https://api.github.com/repos/pro-collection/interview-question/issues/1089/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/1089/comments","https://api.github.com/repos/pro-collection/interview-question/issues/1089/events","https://github.com/pro-collection/interview-question/issues/1089",2778229308,"I_kwDOJGDC6c6lmGo8",1089,"vite 与 esbuild 是关系【热度: 55】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[191,192],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":193,"_68":194,"_54":195,"_113":196,"_115":197,"_117":26,"_118":198},5312231007,"LA_kwDOJGDC6c8AAAABPKI2Xw","https://api.github.com/repos/pro-collection/interview-question/labels/%E9%98%BF%E9%87%8C%E5%B7%B4%E5%B7%B4","阿里巴巴","ededed","公司标签",[],{"_54":128,"_64":129,"_58":130,"_66":131,"_68":132,"_70":133,"_72":134,"_118":135,"_136":201,"_138":139,"_140":141,"_120":121,"_142":143,"_144":145,"_146":-5,"_147":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2025-01-09T16:09:00Z",{"_155":141,"_156":141,"_157":141},"**关键词**：vite 与 esbuild\n\n1. **Vite 对 Esbuild 的依赖关系（构建阶段）**\n\n - **代码转换和打包工具**：在 Vite 的构建过程（`vite build`）中，Esbuild 扮演了重要的角色。Esbuild 是一个超高速的 JavaScript 打包器，Vite 利用 Esbuild 来进行代码的转换和初步打包。它能够快速地将 ES 模块（ESM）进行处理，如解析`import`和`export`语句，把多个模块合并成一个或多个输出文件。\n - **性能优势体现**：Esbuild 的高性能主要体现在其使用 Go 语言编写，具有高度并行化的编译能力。相比传统的打包工具，它能够以极快的速度完成任务。例如，在处理大型项目中的大量 JavaScript 模块时，Esbuild 可以在很短的时间内完成打包工作，这对于 Vite 在构建阶段提高效率非常有帮助。\n\n2. **功能协作关系（在 Vite 生态中的角色）**\n\n - **与 Vite 插件的协作**：Vite 有丰富的插件生态系统，Esbuild 可以和这些插件协作来完成更复杂的构建任务。例如，在处理 CSS、TS（TypeScript）等文件时，Vite 插件可以在 Esbuild 的基础上进行进一步的处理。当 Esbuild 完成对 JavaScript 模块的初步打包后，Vite 插件可以对打包后的文件进行优化，如压缩、添加代码注释等操作。\n - **在不同模块类型处理中的分工**：对于不同类型的模块，Vite 和 Esbuild 有不同的处理方式。Esbuild 主要专注于 JavaScript 模块的快速打包和转换，而 Vite 则负责整体的构建流程协调，包括对 CSS 文件的处理（如解析`@import`语句）、静态资源的处理（如图片、字体的加载路径优化）以及模块热替换（HMR）等开发阶段的功能。例如，在处理一个包含 JavaScript、CSS 和图片的项目时，Esbuild 会快速打包 JavaScript 模块，Vite 则会确保 CSS 正确加载并且图片资源能够被正确引用。\n\n3. **Vite 开发阶段与 Esbuild 的关联（相对较弱）**\n - **开发模式下的功能侧重不同**：在 Vite 开发阶段，其主要利用浏览器原生 ES 模块的支持来实现快速的模块加载和模块热替换，Esbuild 的打包功能在这个阶段没有像在构建阶段那样被大量使用。Vite 开发服务器会在浏览器请求模块时即时提供相应的 ES 模块文件，而不是依赖 Esbuild 进行预先打包。\n - **潜在的间接关联**：不过，在开发阶段，Vite 的一些配置选项和底层机制可能会和 Esbuild 产生间接关联。例如，在配置`vite.config.js`文件时，一些关于模块解析、路径别名等设置可能会影响到后续构建阶段 Esbuild 的工作方式。同时，开发阶段对模块的处理方式也为构建阶段 Esbuild 的高效打包提供了基础，如准确的模块依赖关系等信息。\n",{"_54":206,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/1089/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/1089/timeline",{"_54":209,"_56":57,"_58":210,"_60":211,"_62":212,"_64":213,"_66":214,"_68":215,"_70":216,"_72":217,"_74":218,"_107":219,"_120":121,"_122":26,"_123":-5,"_124":222,"_126":223,"_148":141,"_142":225,"_144":225,"_147":-5,"_151":152,"_153":226,"_158":-5,"_159":227,"_161":228,"_173":230,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/1088","https://api.github.com/repos/pro-collection/interview-question/issues/1088/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/1088/comments","https://api.github.com/repos/pro-collection/interview-question/issues/1088/events","https://github.com/pro-collection/interview-question/issues/1088",2778226432,"I_kwDOJGDC6c6lmF8A",1088,"vite 在开发过程中，是如何处理 TS 文件的【热度: 112】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[220,221],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":193,"_68":194,"_54":195,"_113":196,"_115":197,"_117":26,"_118":198},[],{"_54":128,"_64":129,"_58":130,"_66":131,"_68":132,"_70":133,"_72":134,"_118":135,"_136":224,"_138":139,"_140":141,"_120":121,"_142":143,"_144":145,"_146":-5,"_147":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2025-01-09T16:07:37Z",{"_155":141,"_156":141,"_157":141},"**关键词**：vite、开发、TS\n\n1. **即时编译 TS 文件**\n\n - **原理**：在 Vite 开发过程中，它利用浏览器原生 ES 模块（ESM）的支持，对于 TypeScript（TS）文件，Vite 会在浏览器请求时即时将其编译为 JavaScript。这个编译过程是由 Vite 内部的插件机制和 TypeScript 编译器（tsc）相关工具完成的。当浏览器请求一个 TS 文件时，Vite 会在服务器端快速地将其转换为浏览器能够理解的 JavaScript 代码。\n - **示例操作**：假设在一个 Vite 项目中有一个`main.ts`文件作为入口文件，其中包含了 TypeScript 代码，如`const message: string = \"Hello, Vite\";`。当浏览器访问`main.ts`时，Vite 会在服务器端将这个 TS 文件编译为 JavaScript 代码（类似于`var message = \"Hello, Vite\";`），然后将编译后的 JavaScript 发送给浏览器，浏览器就可以正常地解析和执行这个文件。\n\n2. **类型检查与开发体验优化**\n\n - **类型检查独立于编译过程**：Vite 在开发过程中会将 TypeScript 的类型检查和代码编译分开。它主要关注代码的编译，以确保浏览器能够运行代码，而类型检查可以通过单独的进程来完成。这样做的好处是，即使类型检查出现错误，也不会影响代码的即时编译和在浏览器中的运行，开发者可以在看到代码运行效果的同时，在编辑器（如 VS Code）中根据类型检查的提示来修复代码中的类型问题。\n - **利用 IDE 的类型检查功能**：Vite 项目通常会配合支持 TypeScript 的 IDE（集成开发环境）来提供更好的开发体验。IDE 可以实时地对 TypeScript 代码进行类型检查，当开发者编写代码时，IDE 会根据代码中的类型定义和引用情况及时地显示错误和提示信息。例如，在 VS Code 中，当编写一个函数参数类型错误的 TypeScript 代码时，编辑器会立即在代码行旁边显示红色波浪线，并提供错误信息，帮助开发者快速定位和修复类型错误。\n\n3. **模块解析与 TS 模块支持**\n\n - **正确解析 TS 模块导入和导出**：Vite 能够正确地解析 TypeScript 中的模块导入（`import`）和导出（`export`）语句。无论是 ES 模块风格的导入导出，还是 CommonJS 风格（在 TypeScript 中也可以使用）的模块交互方式，Vite 都可以处理。例如，在一个 TS 文件中，如果有`import { functionA } from './utils.ts';`这样的导入语句，Vite 会准确地找到`utils.ts`文件，并将其编译和处理后提供给当前文件使用。\n - **支持 TS 模块的热替换（HMR）**：和 JavaScript 模块类似，Vite 也支持 TypeScript 模块的热替换。当修改了一个 TS 模块后，Vite 会通过模块热替换机制将更新后的模块发送给浏览器，浏览器会用新模块替换旧模块，同时保持应用的状态。例如，在一个 Vite + React + TS 项目中，如果修改了一个 React 组件的 TSX（TypeScript XML）文件，Vite 会检测到这个变化，通过 HMR 更新这个组件，而不会刷新整个页面。\n\n4. **TS 配置文件（`tsconfig.json`）的协同工作**\n - **读取和应用配置选项**：Vite 会读取项目中的`tsconfig.json`文件来确定 TypeScript 的编译选项。这个文件包含了如目标 JavaScript 版本（`target`）、模块解析方式（`module`）、是否包含类型检查（`noEmitOnError`等选项）等重要信息。Vite 会根据这些配置来正确地编译 TypeScript 文件。例如，如果`tsconfig.json`中设置了`target`为`ES6`，Vite 会将 TS 文件编译为符合 ES6 标准的 JavaScript 代码。\n - **配置文件的更新与 Vite 的响应**：当`tsconfig.json`文件被修改时，Vite 会根据新的配置重新调整对 TypeScript 文件的编译方式。例如，如果在`tsconfig.json`中添加了一个新的路径别名（`paths`选项）用于模块引用，Vite 会识别这个变化，并在后续的模块解析过程中正确地使用这个路径别名来查找和处理相关的 TS 模块。\n\n---\n\n**编译细节**\n\n1. **Vite 的 TS 插件系统工作机制**\n\n - **利用`vite-plugin-typescript`插件**：Vite 在开发过程中通过`vite-plugin-typescript`插件来处理 TypeScript 文件的即时编译。这个插件会在 Vite 开发服务器启动时被加载并初始化。它会自动检测项目中的`tsconfig.json`文件，以获取 TypeScript 的编译选项，如目标编译版本、模块解析规则等。\n - **监听文件变化**：插件会建立一个文件监听器，用于实时监测 TypeScript 文件的变化。当有 TS 文件被修改（例如，保存文件后），插件会立即捕获到这个变化。例如，在开发过程中，当开发者在编辑器中保存了一个`main.ts`文件，插件会察觉到这个文件更新事件。\n\n2. **编译过程细节**\n\n - **语法解析与类型检查（部分）**：插件会首先对 TypeScript 文件进行语法解析，这类似于 TypeScript 编译器（`tsc`）的前端工作。它会检查代码的语法是否正确，包括变量声明、函数定义、类型注解等方面。不过，Vite 中的 TS 插件在开发阶段主要关注代码的编译，对于严格的类型检查，它会和其他工具（如编辑器的 TS 插件）协同工作。例如，对于`const num: number = \"abc\"`这样的错误类型赋值，插件会在编译过程中识别语法问题，但可能不会像完整的`tsc`检查那样提供详细的类型错误链。\n - **转换为 JavaScript 代码**：在解析语法之后，插件会根据`tsconfig.json`中的目标版本（如`ESNext`、`ES6`等）和其他编译规则，将 TypeScript 代码转换为 JavaScript 代码。这个转换过程涉及到诸多 TypeScript 特性的处理，如类型擦除（去除类型注解）、箭头函数转换（如果目标版本较低）、装饰器处理（如果使用）等。例如，对于一个 TypeScript 的箭头函数`const add = (a: number, b: number): number => a + b;`，如果目标版本是`ES5`，插件可能会将其转换为`function add(a, b) { return a + b; }`形式的 JavaScript 函数。\n - **处理模块导入和导出**：插件能够正确处理 TypeScript 中的模块导入（`import`）和导出（`export`）。无论是 ES 模块风格还是 CommonJS 风格的模块交互，插件都会确保在编译后的 JavaScript 中保持正确的模块引用。例如，对于`import { func } from './module.ts';`这样的 TS 模块导入，插件会在编译`module.ts`后，将其正确地转换为 JavaScript 模块引用，使得在浏览器环境中能够正确加载和执行。\n\n3. **与浏览器交互和代码发送**\n - **生成符合浏览器加载的代码格式**：经过编译后的 JavaScript 代码会被格式化为符合浏览器 ES 模块加载的形式。Vite 会确保代码中的模块导入路径、变量声明等都符合浏览器的原生 ES 模块规范。例如，编译后的代码可能会有类似于`import * as module from './module.js';`这样的标准 ES 模块导入语句，其中`.js`扩展名是在编译过程中添加的（即使原始文件是`.ts`），以满足浏览器对模块文件扩展名的识别要求。\n - **即时发送给浏览器**：一旦编译完成，Vite 会立即将编译后的 JavaScript 代码发送给浏览器。当浏览器请求一个 TypeScript 文件时，Vite 能够快速地完成编译并提供编译后的代码，使得浏览器可以像加载普通 JavaScript 模块一样加载和执行这些代码。例如，当浏览器通过`import { app } from './main.ts';`请求`main.ts`时，Vite 会编译`main.ts`为 JavaScript 并发送给浏览器，让浏览器能够顺利地执行应用程序的入口代码。\n",{"_54":229,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/1088/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/1088/timeline",{"_54":232,"_56":57,"_58":233,"_60":234,"_62":235,"_64":236,"_66":237,"_68":238,"_70":239,"_72":240,"_74":241,"_107":242,"_120":121,"_122":26,"_123":-5,"_124":245,"_126":246,"_148":141,"_142":248,"_144":248,"_147":-5,"_151":152,"_153":249,"_158":-5,"_159":250,"_161":251,"_173":253,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/1087","https://api.github.com/repos/pro-collection/interview-question/issues/1087/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/1087/comments","https://api.github.com/repos/pro-collection/interview-question/issues/1087/events","https://github.com/pro-collection/interview-question/issues/1087",2778212060,"I_kwDOJGDC6c6lmCbc",1087,"vite 开发和构建有何不同？【热度: 292】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[243,244],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":193,"_68":194,"_54":195,"_113":196,"_115":197,"_117":26,"_118":198},[],{"_54":128,"_64":129,"_58":130,"_66":131,"_68":132,"_70":133,"_72":134,"_118":135,"_136":247,"_138":139,"_140":141,"_120":121,"_142":143,"_144":145,"_146":-5,"_147":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2025-01-09T16:00:57Z",{"_155":141,"_156":141,"_157":141},"**关键词**：vite、开发、构建\n\n1. **开发阶段**\n\n - **快速的模块加载**\n - **原理**：在开发阶段，Vite 充分利用浏览器对原生 ES 模块（ESM）的支持。当浏览器请求一个模块时，Vite 直接将对应的 ES 模块文件发送给浏览器，而不需要像传统构建工具那样先进行打包。这使得模块加载速度非常快，因为浏览器可以直接解析和执行这些原生模块。\n - **示例**：假设在一个 Vite 项目中有`main.js`和`utils.js`两个模块，`main.js`通过`import { someFunction } from './utils.js';`来引用`utils.js`中的函数。在开发服务器启动后，当浏览器访问`main.js`并遇到这个`import`语句时，Vite 会直接将`utils.js`发送给浏览器，浏览器能够快速地加载和执行这个模块。\n - **高效的模块热替换（HMR）**\n - **原理**：Vite 的 HMR 功能允许在修改代码后，只更新发生变化的模块，而不需要刷新整个页面。它通过建立一个 WebSocket 连接来实时监听文件变化。当一个模块被修改后，Vite 会将更新后的模块发送给浏览器，浏览器会用新模块替换旧模块，同时保持应用的当前状态。\n - **示例**：如果在上述`utils.js`模块中修改了`someFunction`的实现，Vite 会检测到这个变化，通过 WebSocket 将更新后的`utils.js`发送给浏览器。浏览器接收到新模块后，会更新`main.js`中对`someFunction`的引用，并且应用的其他部分状态（如组件的局部状态）可以保持不变，从而实现了快速的热替换，提高了开发效率。\n - **开发服务器的便利性**\n - **原理**：Vite 提供了一个轻量级的开发服务器，它可以快速启动并且自动处理一些常见的开发任务，如解析`import`语句、处理 CSS 的`@import`等。这个开发服务器还支持一些开发时的功能，如自动打开浏览器、代理请求等。\n - **示例**：在启动 Vite 开发服务器后，它可以自动打开默认浏览器并访问项目的首页。如果项目需要从后端 API 获取数据，并且开发环境和生产环境的 API 地址不同，Vite 的开发服务器可以通过配置代理，将前端请求转发到正确的后端 API 地址，方便开发过程中的联调。\n\n2. **构建阶段（主要是`vite build`）**\n - **代码打包与优化**\n - **原理**：在构建阶段，Vite 使用 Rollup 作为打包工具（在`vite build`过程中）。Rollup 会对项目中的所有 ES 模块进行静态分析，将它们打包成一个或多个适合生产环境的文件。这个过程包括 Tree - Shaking（摇树优化），即剔除未使用的代码，以及作用域提升（Scope Hoisting）来优化代码结构，减少变量查找的层级，从而生成更紧凑、高效的代码。\n - **示例**：假设有一个包含多个工具函数的`utils.js`模块，如`export const add = (a, b) => a + b;`，`export const subtract = (a, b) => a - b;`等。在`main.js`中只使用了`add`函数，通过`import { add } from './utils.js';`引用。在构建过程中，Rollup 会通过 Tree - Shaking 检测到`subtract`等未使用的函数，不会将它们打包到最终的输出文件中，减小了文件大小。\n - **资源处理与整合**\n - **原理**：Vite 在构建阶段会对各种资源（如 CSS、静态图像、字体等）进行处理。对于 CSS，它会将`@import`语句解析并将相关的 CSS 文件合并，还可能进行压缩和代码转换。对于静态资源，它会根据配置将它们复制到输出目录，并可能对文件名进行哈希处理，以方便缓存管理。\n - **示例**：如果项目中有一个`styles.css`文件，其中通过`@import`导入了其他 CSS 文件，如`@import 'normalize.css';`。在构建时，Vite 会将`normalize.css`和`styles.css`合并成一个或多个 CSS 文件，并将它们放置在输出目录的合适位置，同时可能会对 CSS 进行压缩，减少文件大小，提高页面加载速度。\n - **输出格式和部署准备**\n - **原理**：构建阶段会根据配置生成适合生产环境部署的文件格式。Vite 可以生成多种格式的输出，如`umd`、`es`、`cjs`等，以满足不同的部署场景。例如，`umd`格式可以用于在浏览器中通过`\n \n \n \n ```\n - 在这里，`your - main - app - bundle.js`是 Webpack 打包后的应用程序主文件。当 Webpack 在代码中遇到`import _ from 'lodash';`语句时，它不会将`lodash`的代码打包进输出文件，而是假设`lodash`已经在运行时环境中存在，并且可以通过全局变量`lodash`访问。所以在打包后的 JavaScript 代码中，实际上是通过全局变量来引用外部依赖的。\n\n3. **在其他运行环境（如 Node.js）中的加载方式（以 CommonJS 模块为例）**\n\n - **配置`externals`类似操作**：\n - 在 Webpack 配置文件中，对于要作为外部依赖处理的模块（假设是`axios`，用于在 Node.js 环境中进行 HTTP 请求），配置`externals`如下：\n ```javascript\n module.exports = {\n //...其他配置\n externals: {\n axios: \"axios\",\n },\n };\n ```\n - **运行时环境中的模块引用**：\n - 在 Node.js 应用程序代码中，需要确保`axios`已经作为一个 CommonJS 模块安装在项目的`node_modules`目录下或者在全局环境中有相应的模块路径。当运行打包后的代码时，Webpack 不会打包`axios`，而是期望在 Node.js 的模块加载机制中找到它。例如，在打包后的 Node.js 代码中可能会有类似这样的引用：\n ```javascript\n const axios = require(\"axios\");\n ```\n - 此时，Node.js 会按照自己的模块加载规则去查找`axios`模块，就像没有经过 Webpack 打包一样。这是因为 Webpack 通过`externals`配置将`axios`模块的加载责任交给了运行时环境的模块加载系统。\n\n4. **AMD（Asynchronous Module Definition）模块加载方式（适用于支持 AMD 的环境）**\n - **配置`externals`和模块定义**：\n - 假设在一个支持 AMD 的浏览器环境或者 JavaScript 运行环境中，有一个名为`backbone`的外部依赖，在 Webpack 配置文件中设置`externals`：\n ```javascript\n module.exports = {\n //...其他配置\n externals: {\n backbone: \"backbone\",\n },\n };\n ```\n - **AMD 模块加载脚本**：\n - 在 HTML 文件或者 AMD 模块加载器的配置文件中，需要使用 AMD 的方式来加载`backbone`模块。例如，在一个简单的 AMD 配置中，可能会有如下代码来加载`backbone`和应用程序主模块：\n ```html\n \n \n \n \n \n \n \n \n \n \n ```\n - 这里使用`require.js`作为 AMD 模块加载器，通过`require.config`配置`backbone`模块的路径，然后在`require`函数中加载应用程序主模块和`backbone`模块。Webpack 在打包过程中，由于`externals`配置，知道`backbone`是外部依赖，会正确地处理代码中的引用，使得在运行时可以通过 AMD 模块加载器来加载`backbone`模块并正确地执行应用程序。\n",{"_54":396,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/1075/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/1075/timeline",{"_54":399,"_56":57,"_58":400,"_60":401,"_62":402,"_64":403,"_66":404,"_68":405,"_70":406,"_72":407,"_74":408,"_107":409,"_120":121,"_122":26,"_123":-5,"_124":411,"_126":412,"_148":141,"_142":414,"_144":414,"_147":-5,"_151":152,"_153":415,"_158":-5,"_159":416,"_161":417,"_173":419,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/1074","https://api.github.com/repos/pro-collection/interview-question/issues/1074/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/1074/comments","https://api.github.com/repos/pro-collection/interview-question/issues/1074/events","https://github.com/pro-collection/interview-question/issues/1074",2685228473,"I_kwDOJGDC6c6gDVW5",1074,"[webpack] 在编译产物的时候，要区分 source 代码和外部依赖代码，该如何处理【热度: 125】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[410],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":128,"_64":129,"_58":130,"_66":131,"_68":132,"_70":133,"_72":134,"_118":135,"_136":413,"_138":139,"_140":141,"_120":121,"_142":143,"_144":145,"_146":-5,"_147":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2024-11-23T03:31:59Z",{"_155":141,"_156":141,"_157":141},"**关键词**：webpack 产物\n\n1. **使用 Webpack 的`optimize-module-ids`插件（用于区分模块来源）**\n\n - **原理**：Webpack 在打包过程中会为每个模块分配一个唯一的`module.id`。`optimize-module-ids`插件可以帮助控制模块标识符的生成方式，使得能够根据模块是源文件还是外部依赖来区分它们。\n - **配置步骤**：\n\n - 首先，安装`optimize-module-ids`插件（可能需要自行开发类似功能插件或寻找已有合适插件）。\n - 然后，在 Webpack 配置文件中添加插件配置。例如：\n\n ```javascript\n const CustomModuleIdsPlugin = require(\"optimize-module-ids\");\n module.exports = {\n //...其他配置\n plugins: [\n new CustomModuleIdsPlugin((module) => {\n if (module.resource && module.resource.includes(\"node_modules\")) {\n return \"external\";\n } else {\n return \"source\";\n }\n }),\n ],\n };\n ```\n\n 这个插件会依据模块的资源路径（`module.resource`）来判别模块是源自`node_modules`（外部依赖）还是其他源文件路径。若为外部依赖，模块的`id`会被标记为`external`，否则标记为`source`。如此一来，在最终的打包产物或构建信息里，就能通过这个`id`区分不同来源的模块。\n\n2. **通过构建工具的输出信息区分（适用于简单区分）**\n\n - **查看构建日志**：Webpack 在构建过程中会输出大量的日志信息。可在构建日志里查找模块的路径信息以区分源文件和外部依赖。比如，日志中来自`src`目录的模块通常是源文件，而来自`node_modules`目录的模块则是外部依赖。\n - **分析统计信息（`stats`）**：Webpack 提供了`stats`选项，可生成详细的构建统计信息。通过将`stats`配置为`'verbose'`或其他详细级别，能获取每个模块的路径、大小、依赖关系等信息。在这些信息中，可轻易识别出源文件和外部依赖。例如，配置`stats`如下：\n\n ```javascript\n module.exports = {\n //...其他配置\n stats: \"verbose\",\n };\n ```\n\n 之后便可通过分析生成的统计文件或在终端输出的详细统计信息来区分不同来源的模块。\n\n3. **自定义打包结构或命名规则（在输出阶段区分）**\n\n - **分离输出目录**：在 Webpack 的输出配置（`output`）中，可以设置不同的输出路径来分离源文件和外部依赖的打包产物。例如：\n\n ```javascript\n module.exports = {\n //...其他配置\n output: {\n path: path.resolve(__dirname, \"dist\"),\n filename: (chunkData) => {\n if (chunkData.chunk.name.includes(\"external\")) {\n return \"external-bundles/[name].js\";\n } else {\n return \"source-bundles/[name].js\";\n }\n },\n },\n };\n ```\n\n 这里依据模块所属的`chunk`名称（可在构建过程中通过某些方式将模块所属的`chunk`标记为`external`或`source`），把外部依赖和源文件分别打包到不同的目录（`external-bundles`和`source-bundles`）下，这样在最终的打包产物中就能很直观地进行区分。\n\n - **命名规则**：除了分离输出目录，还可通过命名规则来区分。例如，在输出文件名中添加前缀以表示模块来源，如`source-[name].js`和`external-[name].js`，如此在查看打包文件时就能快速识别模块来源。\n",{"_54":418,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/1074/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/1074/timeline",{"_54":421,"_56":57,"_58":422,"_60":423,"_62":424,"_64":425,"_66":426,"_68":427,"_70":428,"_72":429,"_74":430,"_107":431,"_120":121,"_122":26,"_123":-5,"_124":433,"_126":434,"_148":141,"_142":447,"_144":448,"_147":-5,"_151":152,"_153":449,"_158":-5,"_159":450,"_161":451,"_173":453,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/1073","https://api.github.com/repos/pro-collection/interview-question/issues/1073/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/1073/comments","https://api.github.com/repos/pro-collection/interview-question/issues/1073/events","https://github.com/pro-collection/interview-question/issues/1073",2685223512,"I_kwDOJGDC6c6gDUJY",1073,"corejs 是做什么用的，跟 Polyfill 是什么关系【热度: 100】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[432],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":435,"_64":436,"_58":437,"_66":438,"_68":439,"_70":440,"_72":441,"_118":442,"_136":443,"_138":444,"_140":141,"_120":121,"_142":445,"_144":446,"_146":-5,"_147":-5},"https://api.github.com/repos/pro-collection/interview-question/milestones/2","https://github.com/pro-collection/interview-question/milestone/2","https://api.github.com/repos/pro-collection/interview-question/milestones/2/labels",9124545,"MI_kwDOJGDC6c4AizrB",2,"中","中级程序面试问题",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},491,"2023-03-06T15:00:15Z","2025-02-10T16:32:39Z","2024-11-23T03:25:28Z","2024-11-23T03:25:29Z",{"_155":141,"_156":141,"_157":141},"**关键词**：corejs 和 Polyfill\n\n1. **CoreJs 的作用**\n\n - **提供标准的 JavaScript 功能支持**：CoreJs 是一个 JavaScript 标准库，它提供了许多在现代 JavaScript 环境中被认为是标准的功能。这些功能包括但不限于对 ES6 + 语法的支持，如`Promise`、`Symbol`、`Map`、`Set`等。例如，在一些较旧的浏览器中可能没有原生的`Promise`支持，CoreJs 可以提供一个兼容的`Promise`实现，使得代码能够在这些浏览器中正确运行。\n - **跨浏览器兼容性支持**：它能够填补不同浏览器之间的 JavaScript 功能差距。由于不同浏览器对 JavaScript 标准的实现进度不同，CoreJs 可以确保在各种浏览器环境下都能提供一致的功能。比如，某些浏览器可能没有完全实现`Array.prototype.includes`方法，CoreJs 可以添加这个方法的实现，使得应用程序在这些浏览器中也能使用该功能。\n - **模块化的功能提供**：CoreJs 是模块化的，这意味着可以根据具体的需求选择引入特定的模块。例如，如果只需要在项目中添加`Promise`和`Map`的支持，而不需要其他功能，可以只引入 CoreJs 相关的模块，避免不必要的代码体积增加。\n\n2. **CoreJs 与 Polyfill 的关系**\n - **CoreJs 是 Polyfill 的一种实现方式**：Polyfill 是一个术语，用于描述一段代码，它提供了浏览器中缺失的功能。CoreJs 可以看作是一种全面的 Polyfill 库。当浏览器不支持某个 JavaScript 特性时，CoreJs 可以通过添加相应的代码来模拟该特性，就像填充了浏览器功能的空缺一样。例如，对于`Object.assign`方法，如果浏览器不支持，CoreJs 可以提供一个自定义的函数来实现相同的功能，这个自定义函数就是一种 Polyfill。\n - **Polyfill 可以有多种来源，CoreJs 是常用的一种**：除了 CoreJs 之外，开发人员也可以自己编写 Polyfill 或者使用其他库来提供类似的功能。但是 CoreJs 是经过广泛测试和优化的，它涵盖了大量的 JavaScript 特性，并且能够很好地与 Babel 等工具配合使用。例如，在 Babel 的`@babel/preset - env`配置中，使用`useBuiltIns: 'usage'`选项时，Babel 会根据目标浏览器的情况，自动引入 CoreJs 中的相关 Polyfill，以确保代码在目标浏览器中能够正确运行。这样就能够高效地为项目添加必要的 Polyfill，而不是无差别地引入所有可能的 Polyfill，从而减小代码体积。\n",{"_54":452,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/1073/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/1073/timeline",{"_54":455,"_56":57,"_58":456,"_60":457,"_62":458,"_64":459,"_66":460,"_68":461,"_70":462,"_72":463,"_74":464,"_107":465,"_120":121,"_122":26,"_123":-5,"_124":467,"_126":468,"_148":141,"_142":470,"_144":471,"_147":-5,"_151":152,"_153":472,"_158":-5,"_159":473,"_161":474,"_173":476,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/1072","https://api.github.com/repos/pro-collection/interview-question/issues/1072/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/1072/comments","https://api.github.com/repos/pro-collection/interview-question/issues/1072/events","https://github.com/pro-collection/interview-question/issues/1072",2685221785,"I_kwDOJGDC6c6gDTuZ",1072,"[Webpack] 我如何实现在高版本浏览器上使用 es6 产物，在低版本上使用 es5【热度: 122】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[466],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":128,"_64":129,"_58":130,"_66":131,"_68":132,"_70":133,"_72":134,"_118":135,"_136":469,"_138":139,"_140":141,"_120":121,"_142":143,"_144":145,"_146":-5,"_147":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2024-11-23T03:23:47Z","2024-11-23T03:23:48Z",{"_155":141,"_156":141,"_157":141},"**关键词**：Webpack es6 产物\n\n1. **分别打包 ES5 和 ES6 产物（从一份 ES6 源码）**\n\n - **配置 Webpack 和 Babel 基础环境**\n - 首先，安装必要的依赖。除了 Webpack 本身相关的依赖外，还需要`babel - loader`、`@babel/core`和`@babel/preset - env`。\n ```bash\n npm install webpack webpack - cli babel - loader @babel/core @babel/preset - env --save - dev\n ```\n - 创建 Webpack 配置文件（例如`webpack.config.js`），并在其中配置基本的模块规则，用于处理 JavaScript 文件。先配置一个简单的 ES6 打包规则：\n ```javascript\n const path = require(\"path\");\n module.exports = {\n entry: \"./src/index.js\", // 假设ES6源码入口文件是index.js\n output: {\n filename: \"es6 - bundle.js\",\n path: path.resolve(__dirname, \"dist/es6\"),\n },\n module: {\n rules: [\n {\n test: /\\.js$/,\n exclude: /node_modules/,\n use: {\n loader: \"babel - loader\",\n options: {\n presets: [\n [\n \"@babel/preset - env\",\n {\n targets: {\n // 设置一个较高的浏览器版本支持ES6原生，这里假设现代浏览器都支持\n chrome: \"80\",\n firefox: \"70\",\n },\n },\n ],\n ],\n },\n },\n },\n ],\n },\n };\n ```\n - **添加 ES5 打包配置**\n - 为了打包 ES5 产物，在 Webpack 配置文件中添加另一个配置对象。可以通过`webpack - merge`工具（需要安装`webpack - merge`）来合并基础配置和 ES5 特定配置，避免重复配置。\n ```javascript\n const path = require(\"path\");\n const webpackMerge = require(\"webpack - merge\");\n const baseConfig = {\n entry: \"./src/index.js\",\n output: {\n filename: \"es6 - bundle.js\",\n path: path.resolve(__dirname, \"dist/es6\"),\n },\n module: {\n rules: [\n {\n test: /\\.js$/,\n exclude: /node_modules/,\n use: {\n loader: \"babel - loader\",\n options: {\n presets: [\n [\n \"@babel/preset - env\",\n {\n targets: {\n chrome: \"80\",\n firefox: \"70\",\n },\n },\n ],\n ],\n },\n },\n },\n ],\n },\n };\n const es5Config = {\n output: {\n filename: \"es5 - bundle.js\",\n path: path.resolve(__dirname, \"dist/es5\"),\n },\n module: {\n rules: [\n {\n test: /\\.js$/,\n exclude: /node_modules/,\n use: {\n loader: \"babel - loader\",\n options: {\n presets: [\n [\n \"@babel/preset - env\",\n {\n targets: {\n // 设置较低的浏览器版本，确保转换为ES5语法\n chrome: \"50\",\n firefox: \"40\",\n },\n useBuiltIns: \"usage\",\n corejs: 3,\n },\n ],\n ],\n },\n },\n },\n ],\n },\n };\n module.exports = [baseConfig, webpackMerge(baseConfig, es5Config)];\n ```\n - 上述配置中，`es5Config`部分重新定义了输出文件名和路径，并且在`babel - loader`的选项中，通过`@babel/preset - env`的`targets`选项设置了较低的浏览器支持范围，这样就可以将源码转换为 ES5 语法并打包到`dist/es5`目录下的`es5 - bundle.js`文件。\n\n2. **区分加载 ES5 还是 ES6 产物**\n - **使用浏览器特性检测脚本（HTML + JavaScript）**\n - 在 HTML 文件（假设是`index.html`）中，可以添加一段 JavaScript 代码来检测浏览器是否支持 ES6 特性。例如，检测`Promise`是否存在（`Promise`是 ES6 的一个典型特性）。\n ```html\n \n \n \n \n Document\n \n \n \n \n \n ```\n - 这种方法简单直接，但有一定的局限性。如果浏览器对 ES6 的支持不完全（例如，支持部分 ES6 语法但不支持检测的特性），可能会导致加载错误的产物。\n - **使用服务端渲染（SSR）或构建时检测（更高级）**\n - 如果是在服务端渲染的应用中，可以在服务端根据用户代理（User - Agent）来判断浏览器版本，进而选择加载 ES5 还是 ES6 产物。这需要在服务端代码（例如 Node.js 中的 Express 应用）中进行逻辑处理。\n - 另一种构建时检测的方法是，在构建过程中生成一个包含浏览器支持信息的配置文件。可以使用`browserslist`工具（`@babel/preset - env`内部也使用了这个工具来确定目标浏览器）结合一些自定义脚本，在构建时确定目标浏览器范围，然后生成一个配置文件（例如`browser - config.json`），内容可能是`{\"supportsES6\": true}`或者`{\"supportsES6\": false}`。在 HTML 文件中，通过读取这个配置文件来加载相应的产物。\n ```javascript\n // 假设这是一个自定义脚本，用于生成browser - config.json\n const browserslist = require(\"browserslist\");\n const fs = require(\"fs\");\n const targets = {\n chrome: \"50\",\n firefox: \"40\",\n };\n const browsers = browserslist(Object.keys(targets).map((browser) => `${browser} >= ${targets[browser]}`));\n const supportsES6 = browsers.some(\n (browser) => browser.includes(\"Chrome >= 80\") || browser.includes(\"Firefox >= 70\")\n );\n fs.writeFileSync(\"browser - config.json\", JSON.stringify({ supportsES6 }));\n ```\n - 然后在 HTML 文件中：\n ```html\n \n \n \n \n \n \n \n \n \n \n ```\n",{"_54":475,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/1072/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/1072/timeline",{"_54":478,"_56":57,"_58":479,"_60":480,"_62":481,"_64":482,"_66":483,"_68":484,"_70":485,"_72":486,"_74":487,"_107":488,"_120":121,"_122":26,"_123":-5,"_124":490,"_126":491,"_148":141,"_142":493,"_144":494,"_147":-5,"_151":152,"_153":495,"_158":-5,"_159":496,"_161":497,"_173":499,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/1071","https://api.github.com/repos/pro-collection/interview-question/issues/1071/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/1071/comments","https://api.github.com/repos/pro-collection/interview-question/issues/1071/events","https://github.com/pro-collection/interview-question/issues/1071",2685189427,"I_kwDOJGDC6c6gDL0z",1071,"Webpack 与 Vite 在产物结果上有何区别【热度: 420】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[489],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":128,"_64":129,"_58":130,"_66":131,"_68":132,"_70":133,"_72":134,"_118":135,"_136":492,"_138":139,"_140":141,"_120":121,"_142":143,"_144":145,"_146":-5,"_147":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2024-11-23T03:02:02Z","2024-11-23T03:02:03Z",{"_155":141,"_156":141,"_157":141},"**关键词**：Webpack 与 Vite 产物差异\n\n1. **模块格式和加载方式**\n\n - **Webpack**：\n - 在产物中，Webpack 通常会将多个模块打包成一个或多个 bundle 文件。这些 bundle 文件的格式可以是多种形式，如 CommonJS（在 Node.js 环境下常用）或者 IIFE（立即调用函数表达式，用于浏览器环境）。对于浏览器环境，Webpack 会将所有的 JavaScript 模块打包成一个或几个大的文件，并且通过自定义的加载逻辑来加载模块。例如，在一个简单的 Webpack 打包后的 JavaScript 文件中，可能会看到类似`__webpack_require__`这样的函数来实现模块的加载和解析。\n - 这种打包方式会把所有的模块依赖关系都内建在 bundle 文件中，使得浏览器在加载时只需要加载一个或几个文件即可。但如果应用规模较大，bundle 文件可能会变得非常大，导致首次加载时间过长。为了解决这个问题，Webpack 也支持代码分割（Code Splitting），通过动态`import`等方式将代码分割成多个较小的块，在需要的时候再加载。\n - **Vite**：\n - Vite 在产物中更倾向于保留原生 ES 模块（ESM）的格式。在开发阶段，Vite 利用浏览器对 ES 模块的原生支持来加载模块，而在生产阶段，它也会尽量保持这种格式。这意味着浏览器可以利用原生的`\n \n\n```\n\n- 当浏览器加载这个文件时，模块加载函数会开始执行，根据需要动态地加载和执行各个模块。\n",{"_54":702,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/1009/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/1009/timeline",{"_54":705,"_56":57,"_58":706,"_60":707,"_62":708,"_64":709,"_66":710,"_68":711,"_70":712,"_72":713,"_74":714,"_107":715,"_120":121,"_122":26,"_123":-5,"_124":725,"_126":726,"_148":141,"_142":728,"_144":729,"_147":-5,"_151":152,"_153":730,"_158":-5,"_159":731,"_161":732,"_173":734,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/991","https://api.github.com/repos/pro-collection/interview-question/issues/991/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/991/comments","https://api.github.com/repos/pro-collection/interview-question/issues/991/events","https://github.com/pro-collection/interview-question/issues/991",2583573078,"I_kwDOJGDC6c6Z_jJW",991,"部署一个 node 应用要考虑哪些因素【热度: 98】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[716,723,724],{"_66":717,"_68":718,"_54":719,"_113":720,"_115":721,"_117":26,"_118":722},5232525911,"LA_kwDOJGDC6c8AAAABN-ICVw","https://api.github.com/repos/pro-collection/interview-question/labels/Nodejs","Nodejs","AC3F88","Nodejs 研究",{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":268,"_68":269,"_54":270,"_113":271,"_115":197,"_117":26,"_118":198},[],{"_54":128,"_64":129,"_58":130,"_66":131,"_68":132,"_70":133,"_72":134,"_118":135,"_136":727,"_138":139,"_140":141,"_120":121,"_142":143,"_144":145,"_146":-5,"_147":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2024-10-13T02:10:15Z","2024-10-13T02:10:16Z",{"_155":141,"_156":141,"_157":141},"**关键词**：node 应用部署\n\n**一、选择服务器和环境**\n\n1. **服务器选择**：\n\n - 可以选择云服务器提供商（如阿里云、腾讯云、AWS 等）的虚拟服务器或容器服务。根据应用的需求和预算，确定服务器的配置（CPU、内存、存储等）。\n - 考虑服务器的地理位置和网络连接质量，以确保用户能够快速访问应用。\n\n2. **操作系统**：\n - 常见的选择是 Linux 发行版，如 Ubuntu、CentOS 等。Linux 系统具有稳定性、安全性和资源效率高的特点，适合部署服务器应用。\n\n**二、代码准备和优化**\n\n1. **代码审查和测试**：\n\n - 在部署之前，确保代码经过严格的审查和测试。包括单元测试、集成测试和端到端测试，以确保应用的功能和性能符合要求。\n - 检查代码中的潜在安全漏洞，如 SQL 注入、跨站脚本攻击（XSS）等，并采取相应的防范措施。\n\n2. **性能优化**：\n - 对 Node.js 应用进行性能优化，以提高在生产环境中的响应速度和吞吐量。可以采用以下优化措施：\n - 优化数据库查询，避免不必要的查询和复杂的连接。\n - 使用缓存技术，如内存缓存或分布式缓存，减少重复计算和数据库访问。\n - 压缩和优化静态资源，如 CSS、JavaScript 和图片，减少网络传输时间。\n - 配置适当的日志级别，避免过多的日志输出影响性能。\n\n**三、部署方式**\n\n1. **手动部署**：\n\n - 直接将代码上传到服务器，并手动安装和配置所需的依赖项和运行环境。这种方式适用于小型项目或临时部署，但不够自动化和可重复。\n - 步骤如下：\n - 使用 SSH 连接到服务器。\n - 将代码上传到服务器，可以使用 FTP、SCP 或 Git 等方式。\n - 在服务器上安装 Node.js 和所需的依赖项（使用`npm install`或`yarn install`）。\n - 配置应用的环境变量，如数据库连接字符串、端口号等。\n - 启动应用（使用`node app.js`或通过 PM2 等进程管理工具）。\n\n2. **持续集成/持续部署（CI/CD）**：\n - 使用 CI/CD 工具实现自动化的部署流程。这种方式可以提高部署的效率和可靠性，减少人为错误。\n - 常见的 CI/CD 工具包括 Jenkins、Travis CI、CircleCI 等。以下是一般的部署流程：\n - 将代码托管在版本控制系统（如 Git）中。\n - 配置 CI/CD 工具，设置构建和部署的触发器（如代码提交、定时任务等）。\n - 在 CI/CD 管道中，进行代码构建、测试和打包。\n - 将打包后的应用部署到服务器，可以使用 SSH、Docker 等方式。\n - 进行自动化的测试和验证，确保应用在部署后正常运行。\n\n**四、运行和监控**\n\n1. **进程管理**：\n\n - 使用进程管理工具来确保 Node.js 应用在服务器上持续运行。常见的进程管理工具包括 PM2、Forever 等。\n - 这些工具可以监控应用的运行状态，自动重启应用在崩溃或出现错误时，并提供日志管理和性能监控功能。\n\n2. **监控和日志记录**：\n\n - 配置应用的日志记录，以便在生产环境中跟踪应用的运行状态和错误。可以使用日志管理工具，如 Logstash、ELK Stack 等，集中收集和分析日志。\n - 同时，使用监控工具来实时监测应用的性能指标，如 CPU 使用率、内存占用、响应时间等。常见的监控工具包括 New Relic、Datadog、Prometheus 等。\n\n3. **安全措施**：\n - 采取必要的安全措施来保护生产环境中的 Node.js 应用。包括：\n - 配置防火墙，限制对服务器的访问。\n - 使用 HTTPS 加密通信，保护用户数据的安全。\n - 定期更新服务器和应用的软件包，以修复安全漏洞。\n - 实施访问控制，限制对敏感资源的访问。\n",{"_54":733,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/991/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/991/timeline",{"_54":736,"_56":57,"_58":737,"_60":738,"_62":739,"_64":740,"_66":741,"_68":742,"_70":743,"_72":744,"_74":745,"_107":746,"_120":121,"_122":26,"_123":-5,"_124":755,"_126":756,"_148":141,"_142":758,"_144":758,"_147":-5,"_151":152,"_153":759,"_158":-5,"_159":760,"_161":761,"_173":763,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/976","https://api.github.com/repos/pro-collection/interview-question/issues/976/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/976/comments","https://api.github.com/repos/pro-collection/interview-question/issues/976/events","https://github.com/pro-collection/interview-question/issues/976",2569781246,"I_kwDOJGDC6c6ZK7_-",976,"commonjs 模块化中 module.exports 与 exports 有什么区别，该如何选择【热度: 194】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[747,748],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":749,"_68":750,"_54":751,"_113":752,"_115":753,"_117":26,"_118":754},5312047129,"LA_kwDOJGDC6c8AAAABPJ9oGQ","https://api.github.com/repos/pro-collection/interview-question/labels/web%E5%BA%94%E7%94%A8%E5%9C%BA%E6%99%AF","web应用场景","EA4E1E","应用场景类问题",[],{"_54":128,"_64":129,"_58":130,"_66":131,"_68":132,"_70":133,"_72":134,"_118":135,"_136":757,"_138":139,"_140":141,"_120":121,"_142":143,"_144":145,"_146":-5,"_147":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2024-10-07T08:51:26Z",{"_155":141,"_156":141,"_157":141},"**关键词**：模块化导出\n\n在 CommonJS 模块化规范中，`module.exports`与`exports`有以下区别：\n\n**一、`module.exports`**\n\n1. **本质**：\n\n - `module.exports`是一个对象，它代表当前模块要导出的内容。可以将任意类型的值（如函数、对象、字符串等）赋值给`module.exports`来决定模块导出的内容。\n\n2. **作用范围和灵活性**：\n - 可以完全覆盖模块的导出内容。例如，可以直接将一个全新的对象赋值给`module.exports`，从而完全替换模块原本可能通过`exports`添加的属性。\n - 适合需要导出复杂数据结构或多个不同类型的值的情况。例如，可以导出一个包含多个函数和变量的对象。\n\n**二、`exports`**\n\n1. **本质**：\n\n - `exports`最初是一个对`module.exports`的引用。这意味着通过`exports`添加的属性实际上是添加到了`module.exports`所代表的对象上。\n\n2. **局限性**：\n - 如果直接将一个值赋值给`exports`，它将不再是对`module.exports`的引用，而是变成一个独立的变量。此时，模块的导出内容将变为这个新的值，而不是原本期望的通过添加属性到`exports`来构建的导出对象。\n - 例如：\n ```javascript\n exports = function () {\n console.log(\"This is a new function.\");\n };\n ```\n - 在这种情况下，模块将不再导出之前可能通过`exports.xxx = yyy`添加的属性，而是只导出这个新的函数。\n\n**三、选择建议\\*\\***：\n\n1. **简单模块导出单个值**：\n\n - 如果模块只需要导出一个简单的值，如一个函数或一个字符串，可以使用`module.exports`直接赋值的方式。例如：\n\n ```javascript\n module.exports = function add(a, b) {\n return a + b;\n };\n ```\n\n2. **复杂模块构建导出对象**：\n\n - 当模块需要导出多个相关的值或功能时，可以先使用`exports`添加属性，最后确保`module.exports`指向一个包含所有需要导出内容的对象。例如：\n\n ```javascript\n exports.foo = function () {\n console.log(\"foo function.\");\n };\n exports.bar = \"bar value\";\n module.exports = exports; // 确保 module.exports 和 exports 指向同一个对象\n ```\n\n3. **避免混淆和错误**：\n - 理解`module.exports`和`exports`的区别非常重要，以避免在导出模块内容时出现意外的结果。尽量明确使用`module.exports`或遵循使用`exports`的正确方式，避免直接赋值给`exports`而导致错误的导出行为。\n",{"_54":762,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/976/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/976/timeline",{"_54":765,"_56":57,"_58":766,"_60":767,"_62":768,"_64":769,"_66":770,"_68":771,"_70":772,"_72":773,"_74":774,"_107":775,"_120":121,"_122":26,"_123":-5,"_124":778,"_126":779,"_148":141,"_142":781,"_144":782,"_147":-5,"_151":152,"_153":783,"_158":-5,"_159":784,"_161":785,"_173":787,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/970","https://api.github.com/repos/pro-collection/interview-question/issues/970/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/970/comments","https://api.github.com/repos/pro-collection/interview-question/issues/970/events","https://github.com/pro-collection/interview-question/issues/970",2569723165,"I_kwDOJGDC6c6ZKt0d",970,"对于已经 import 但未实际使用的模块使用 webpack 还会对它打包吗【热度: 108】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[776,777],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":193,"_68":194,"_54":195,"_113":196,"_115":197,"_117":26,"_118":198},[],{"_54":435,"_64":436,"_58":437,"_66":438,"_68":439,"_70":440,"_72":441,"_118":442,"_136":780,"_138":444,"_140":141,"_120":121,"_142":445,"_144":446,"_146":-5,"_147":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2024-10-07T08:26:50Z","2024-10-07T08:26:51Z",{"_155":141,"_156":141,"_157":141},"**关键词**：tree-shaking 使用\n\n在使用 Webpack 进行打包时，对于已经导入（import）但未实际使用的模块，通常情况下不会被打包进去，但这也取决于具体的配置和使用场景。\n\n**一、默认行为**\n\n在默认情况下，Webpack 会进行“树摇”（tree shaking）操作。树摇是一种优化技术，它可以检测和移除未被使用的代码。如果一个模块被导入但在代码中没有被实际使用，Webpack 会尝试识别并排除这个模块，以减小最终打包文件的大小。\n\n例如：\n\n```javascript\nimport { someFunction } from \"moduleA\";\n// 如果 someFunction 在后续代码中没有被调用，Webpack 可能会在打包时排除 moduleA 中未被使用的部分。\n```\n\n**二、特殊情况**\n\n然而，在某些情况下，即使模块未被直接使用，也可能会被打包进去：\n\n1. 副作用：如果导入的模块有副作用（例如修改全局状态、注册事件监听器等），即使模块中的具体函数或变量没有被直接使用，Webpack 也可能不会将其排除。因为这些副作用可能对应用的运行产生影响。\n\n - 例如：\n\n ```javascript\n import \"moduleB\"; // moduleB 可能会在导入时执行一些初始化操作，有副作用。\n ```\n\n2. 动态导入：如果使用动态导入（例如通过 import()函数），Webpack 可能无法在打包时确定哪些模块会被实际使用，因此可能会保留一些未被直接使用的模块，以确保在运行时能够正确加载所需的模块。\n\n - 例如：\n\n ```javascript\n const moduleName = \"moduleC\";\n import(moduleName).then((module) => {\n // 使用动态导入的模块。\n });\n ```\n\n3. 第三方库的依赖：如果导入的模块被其他模块间接依赖，即使在当前模块中没有直接使用，也可能会被打包进去。例如，一个第三方库可能依赖于某个特定的模块，而你的代码只导入了这个第三方库，Webpack 可能会将这个被依赖的模块也打包进来。\n",{"_54":786,"_164":178,"_165":178,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/970/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/970/timeline",{"_54":789,"_56":57,"_58":790,"_60":791,"_62":792,"_64":793,"_66":794,"_68":795,"_70":796,"_72":797,"_74":798,"_107":799,"_120":121,"_122":26,"_123":-5,"_124":802,"_126":803,"_148":141,"_142":805,"_144":806,"_147":-5,"_151":152,"_153":807,"_158":-5,"_159":808,"_161":809,"_173":811,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/957","https://api.github.com/repos/pro-collection/interview-question/issues/957/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/957/comments","https://api.github.com/repos/pro-collection/interview-question/issues/957/events","https://github.com/pro-collection/interview-question/issues/957",2569546626,"I_kwDOJGDC6c6ZKCuC",957,"前端需要加载一个大体积的文件时，一般有哪些优化思路【热度: 594】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[800,801],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":268,"_68":269,"_54":270,"_113":271,"_115":197,"_117":26,"_118":198},[],{"_54":128,"_64":129,"_58":130,"_66":131,"_68":132,"_70":133,"_72":134,"_118":135,"_136":804,"_138":139,"_140":141,"_120":121,"_142":143,"_144":145,"_146":-5,"_147":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2024-10-07T07:09:53Z","2024-10-07T07:09:54Z",{"_155":141,"_156":141,"_157":141},"**关键词**：前端加载文件过大\n\n当前端需要加载大体积文件时，可以从以下几个方面进行优化：\n\n**一、文件压缩**\n\n1. **服务器端压缩**：\n\n - 在服务器上配置文件压缩功能，如使用 Gzip 或 Brotli 压缩算法对文件进行压缩后再传输。这样可以显著减少文件的大小，降低传输时间。\n - 例如，在 Nginx 服务器中，可以通过配置开启 Gzip 压缩：\n\n ```nginx\n gzip on;\n gzip_comp_level 6;\n gzip_types text/plain text/css application/javascript application/json image/svg+xml;\n ```\n\n2. **客户端解压缩**：\n - 现代浏览器通常支持对 Gzip 和 Brotli 压缩的文件进行自动解压缩。当浏览器接收到压缩后的文件时，会自动解压缩并使用。\n - 无需额外的客户端代码，浏览器会自动处理压缩文件的解压缩过程，提高文件加载速度。\n\n**二、文件分割与懒加载**\n\n1. **文件分割**：\n\n - 将大体积文件分割成多个较小的文件。例如，对于一个大型的 JavaScript 库，可以将其拆分成多个模块，根据需要逐步加载。\n - 这样可以避免一次性加载整个大文件，减少初始加载时间。\n - 例如，使用 Webpack 等构建工具可以将代码分割成多个 chunk，根据路由或特定条件进行加载。\n\n2. **懒加载**：\n - 对于不是立即需要的文件或资源，可以采用懒加载的方式。当用户实际需要使用该资源时，再进行加载。\n - 例如，对于图片、视频等资源，可以在用户滚动到可视区域时再进行加载，避免在页面初始加载时加载所有资源。\n - 对于 JavaScript 模块，可以使用动态导入（dynamic import）的方式实现懒加载：\n ```javascript\n const loadModule = async () => {\n const module = await import(\"./largeModule.js\");\n // 使用加载的模块\n };\n ```\n\n**三、缓存策略**\n\n1. **浏览器缓存**：\n\n - 设置合理的缓存策略，让浏览器缓存已经加载过的文件。这样，当用户再次访问时，可以直接从缓存中读取文件，而无需再次从服务器下载。\n - 可以通过设置 HTTP 响应头来控制缓存，例如：\n\n ```nginx\n location / {\n add_header Cache-Control \"max-age=3600\";\n }\n ```\n\n - 上述配置将设置文件的缓存时间为 1 小时。\n\n2. **缓存更新机制**：\n - 当文件内容发生变化时，需要确保浏览器能够获取到最新的版本。可以通过在文件名中添加版本号或哈希值来实现缓存更新。\n - 例如，将文件名改为`largeFile_v1.2.js`或`largeFile_abc123.js`，当文件内容变化时，更新版本号或哈希值，浏览器会认为这是一个新的文件并进行下载。\n\n**四、优化加载顺序**\n\n1. **关键资源优先加载**：\n\n - 确定哪些资源是页面加载的关键资源，优先加载这些资源。对于大体积文件，如果不是关键资源，可以延迟加载。\n - 例如，对于一个图片库应用，先加载页面的基本结构和导航部分，图片可以在用户交互时再进行加载。\n\n2. **异步加载**：\n - 使用异步加载的方式加载大体积文件。例如，对于 JavaScript 文件，可以使用`\n ```\n - 这样可以避免阻塞页面的渲染，提高用户体验。\n\n**五、CDN 加速**\n\n1. **使用内容分发网络（CDN）**：\n\n - 将大体积文件托管在 CDN 上，利用 CDN 的分布式节点，可以让用户从离自己最近的节点获取文件，减少网络延迟，提高加载速度。\n - 例如，将图片、视频、静态文件等托管在 CDN 上，通过 CDN 的 URL 进行访问。\n\n2. **CDN 缓存**：\n - CDN 通常会对文件进行缓存，进一步提高文件的加载速度。当文件内容发生变化时，需要及时更新 CDN 上的缓存。\n - 可以通过设置 CDN 的缓存策略或使用版本号等方式来管理 CDN 缓存。\n",{"_54":810,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/957/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/957/timeline",{"_54":813,"_56":57,"_58":814,"_60":815,"_62":816,"_64":817,"_66":818,"_68":819,"_70":820,"_72":821,"_74":822,"_107":823,"_120":121,"_122":26,"_123":-5,"_124":826,"_126":827,"_148":141,"_142":829,"_144":830,"_147":-5,"_151":152,"_153":831,"_158":-5,"_159":832,"_161":833,"_173":835,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/956","https://api.github.com/repos/pro-collection/interview-question/issues/956/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/956/comments","https://api.github.com/repos/pro-collection/interview-question/issues/956/events","https://github.com/pro-collection/interview-question/issues/956",2569533728,"I_kwDOJGDC6c6ZJ_kg",956,"前端部署应该要考虑哪些问题【热度: 310】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[824,825],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":268,"_68":269,"_54":270,"_113":271,"_115":197,"_117":26,"_118":198},[],{"_54":128,"_64":129,"_58":130,"_66":131,"_68":132,"_70":133,"_72":134,"_118":135,"_136":828,"_138":139,"_140":141,"_120":121,"_142":143,"_144":145,"_146":-5,"_147":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2024-10-07T07:03:14Z","2024-10-07T07:03:15Z",{"_155":141,"_156":141,"_157":141},"**关键词**：前端部署\n\n在前端部署到生产环境时，有多个关键问题需要解决：\n\n**一、高可用性与故障应对**\n\n生产环境中，单点故障是必须考虑的问题。若一台物理机突然崩溃，应用需依然能够正常运行。这时可以了解 Kubernetes（k8s）的 Deployment，它能够有效地应对单点故障，确保应用的高可用性。\n\n**二、热更新与用户体验**\n\n热更新也是重要环节。当需要更新应用时，要做到让用户无感知。同样，k8s 的 Deployment 提供了热更新的功能，能够在不影响用户使用的情况下完成应用的更新。\n\n**三、版本回退机制**\n\n如果上线的新版本出现问题，需要有时光回溯的能力，能够快速回退到之前的稳定版本。\n\n**四、负载均衡**\n\n负载均衡能够确保流量均匀分配到各个服务器上，提高系统的性能和稳定性。使用 Nginx 等工具可以实现负载均衡，满足生产环境的需求。\n\n**五、自动扩缩容**\n\n当流量突然增大时，系统需要能够自动扩容以应对压力。反之，流量减少时也应能自动缩容以节省资源。\n\n**六、数据库部署与运维**\n\n数据库部署不建议在 k8s 上进行，可选择本地部署 MySQL 集群或直接上云。同时，还需要具备基本的数据运维能力，如日志收集（ELK 或 EFK）和性能监控等。\n\n**总结**\n要将前端应用成功部署到生产环境，需要解决上述多个问题。自动化 pipeline 也是关键，包括 Jenkins、GitLab、k8s 等工具的组合使用。将这一套组合拳运用好，即使不是非常厉害的高手，达到中级水平，也能在中小型公司中轻松应对各种部署需求，实现高效的生产环境部署和运维。\n",{"_54":834,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/956/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/956/timeline",{"_54":837,"_56":57,"_58":838,"_60":839,"_62":840,"_64":841,"_66":842,"_68":843,"_70":844,"_72":845,"_74":846,"_107":847,"_120":121,"_122":26,"_123":-5,"_124":850,"_126":851,"_148":141,"_142":853,"_144":853,"_147":-5,"_151":152,"_153":854,"_158":-5,"_159":855,"_161":856,"_173":858,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/953","https://api.github.com/repos/pro-collection/interview-question/issues/953/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/953/comments","https://api.github.com/repos/pro-collection/interview-question/issues/953/events","https://github.com/pro-collection/interview-question/issues/953",2553981257,"I_kwDOJGDC6c6YOqlJ",953,"[webpack] tree-shaking 原理【热度: 722】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[848,849],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":268,"_68":269,"_54":270,"_113":271,"_115":197,"_117":26,"_118":198},[],{"_54":128,"_64":129,"_58":130,"_66":131,"_68":132,"_70":133,"_72":134,"_118":135,"_136":852,"_138":139,"_140":141,"_120":121,"_142":143,"_144":145,"_146":-5,"_147":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2024-09-28T03:25:08Z",{"_155":141,"_156":141,"_157":141},"**关键词**：tree-shaking 原理\n\n> 作者备注\n>\n> webpack 热门问题\n\nWebpack 的 Tree Shaking 主要是用来消除未被使用的代码，以减小最终打包文件的体积。其原理如下：\n\n**一、静态分析**\n\n1. 模块依赖分析：\n\n - Webpack 在构建过程中，会对项目中的模块进行依赖分析。它会解析每个模块的内容，确定模块之间的导入和导出关系。\n - 通过分析，可以构建出一个模块依赖图，展示了各个模块之间的引用关系。\n\n2. 识别未使用的代码：\n - 基于模块依赖图，Webpack 可以确定哪些模块被实际使用，哪些模块未被使用。\n - 对于 JavaScript 模块，它可以识别出未被调用的函数、未被访问的变量等。对于其他资源文件，如 CSS 和图片，也可以根据引用情况判断是否被使用。\n\n**二、代码优化**\n\n1. 消除未使用的代码：\n\n - 一旦识别出未使用的代码，Webpack 会在打包过程中将这些代码从最终的输出文件中移除。\n - 这可以显著减小打包文件的大小，提高应用的加载速度和性能。\n\n2. 作用域分析：\n - 在消除未使用的代码时，Webpack 还会进行作用域分析。它会确保在移除代码的过程中，不会影响到实际使用的代码的正确性。\n - 例如，如果一个函数在一个模块中未被使用，但在另一个模块中被间接引用，Webpack 会谨慎处理，避免错误地移除该函数。\n\n**三、实现条件**\n\n1. ES2015 模块语法：\n\n - Tree Shaking 主要依赖于 ES2015 模块语法（`import`和`export`）。这种模块语法是静态的，使得 Webpack 能够在编译时确定模块的导入和导出关系。\n - 相比之下，CommonJS 模块语法（`require`和`module.exports`）是动态的，难以在编译时进行准确的分析。\n\n2. 支持的模块类型：\n - Webpack 不仅可以对 JavaScript 模块进行 Tree Shaking，还可以对一些其他类型的模块进行处理，如 CSS 模块（通过特定的加载器和插件）。\n - 对于不同类型的模块，Webpack 可能会使用不同的技术和策略来实现 Tree Shaking。\n\n总之，Webpack 的 Tree Shaking 通过静态分析模块依赖关系，识别并消除未使用的代码，从而优化打包文件的大小和性能。它依赖于 ES2015 模块语法和准确的模块依赖分析，同时需要注意一些实现条件和潜在的问题。\n",{"_54":857,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/953/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/953/timeline",{"_54":860,"_56":57,"_58":861,"_60":862,"_62":863,"_64":864,"_66":865,"_68":866,"_70":867,"_72":868,"_74":869,"_107":870,"_120":121,"_122":26,"_123":-5,"_124":873,"_126":874,"_148":141,"_142":876,"_144":877,"_147":-5,"_151":152,"_153":878,"_158":-5,"_159":879,"_161":880,"_173":882,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/944","https://api.github.com/repos/pro-collection/interview-question/issues/944/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/944/comments","https://api.github.com/repos/pro-collection/interview-question/issues/944/events","https://github.com/pro-collection/interview-question/issues/944",2553956271,"I_kwDOJGDC6c6YOkev",944,"[webpack] 发中使用的是 esm 和 webpack, 是否可以直接调用 commonjs 模块化的三方包【热度: 359】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[871,872],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":193,"_68":194,"_54":195,"_113":196,"_115":197,"_117":26,"_118":198},[],{"_54":128,"_64":129,"_58":130,"_66":131,"_68":132,"_70":133,"_72":134,"_118":135,"_136":875,"_138":139,"_140":141,"_120":121,"_142":143,"_144":145,"_146":-5,"_147":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2024-09-28T02:18:10Z","2024-09-28T02:18:11Z",{"_155":141,"_156":141,"_157":141},"**关键词**：模块化混用\n\n在使用 Webpack 作为构建工具的项目中，ESM (ECMAScript Modules) 和 CommonJS 模块系统可以混用。\n\nWebpack 提供了对两种模块化标准的支持，能够理解和处理它们之间的差异，使得这两种不同类型的模块可以在同一个项目中共存。\n\n### 混用时的考虑因素\n\n虽然 ESM 和 CommonJS 可以混用，但是还需要注意一些关键的点：\n\n- **导入方式**：当你从一个 ESM 模块中导入 CommonJS 模块时，导入的内容会被当成默认导出处理。这意味着，即使 CommonJS 模块导出了多个成员，你也需要以默认导入的方式来获取整个 `exports` 对象。\n\n ```javascript\n // CommonJS 模块\n module.exports = {\n foo: \"bar\",\n baz: \"qux\",\n };\n\n // 在 ESM 中导入 CommonJS 模块\n import cjsModule from \"./cjs-module\";\n console.log(cjsModule.foo); // 输出: 'bar'\n ```\n\n- **导出方式**：在一个 CommonJS 模块中，你可以通过 `require` 导入一个 ESM，但是这通常需要额外配置，因为 ESM 默认是异步加载的。此外，ESM 模块的导出在被 CommonJS 模块通过 `require` 导入时，必须访问它们的 `default` 属性或使用 `import()` 异步导入语句。\n\n- **动态与静态**：ESM 是静态的，这意味着你不能动态地导入或导出模块，所有的导入和导出必须在模块的顶层发生。CommonJS 模块是动态的，允许你将 `require` 语句放在代码的任何位置。由于这种静态与动态的区别，混用时要考虑代码组织和模块加载顺序。\n\n- **构建与树摇（Tree Shaking）**：Webpack 可以对 ESM 进行树摇优化，以去除未使用的导出。这可以减少最终构建包的大小。由于 CommonJS 模块是动态的，它们不完全支持树摇。如果在意最终包的大小，优先使用 ESM 来编写新模块可能会更好。\n\n### 总结\n\n在 Webpack 下，ESM 和 CommonJS 可以混用，但是混用时需要注意导入导出的细微差别，以及可能对构建优化产生的影响。理解这些模块系统之间的差异，并合理组织代码，可以充分利用 Webpack 提供的灵活性和功能，编写高效且可维护的现代 JavaScript 应用。\n",{"_54":881,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/944/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/944/timeline",{"_54":884,"_56":57,"_58":885,"_60":886,"_62":887,"_64":888,"_66":889,"_68":890,"_70":891,"_72":892,"_74":893,"_107":894,"_120":121,"_122":26,"_123":-5,"_124":897,"_126":898,"_148":141,"_142":900,"_144":900,"_147":-5,"_151":152,"_153":901,"_158":-5,"_159":902,"_161":903,"_173":905,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/889","https://api.github.com/repos/pro-collection/interview-question/issues/889/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/889/comments","https://api.github.com/repos/pro-collection/interview-question/issues/889/events","https://github.com/pro-collection/interview-question/issues/889",2529856908,"I_kwDOJGDC6c6Wyo2M",889,"pnpm install 和 npm install 有何区别",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[895,896],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":193,"_68":194,"_54":195,"_113":196,"_115":197,"_117":26,"_118":198},[],{"_54":435,"_64":436,"_58":437,"_66":438,"_68":439,"_70":440,"_72":441,"_118":442,"_136":899,"_138":444,"_140":141,"_120":121,"_142":445,"_144":446,"_146":-5,"_147":-5},{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},"2024-09-17T02:42:28Z",{"_155":141,"_156":141,"_157":141},"`pnpm install` 和 `npm install` 都是用于安装 JavaScript 项目依赖的命令，但它们背后的包管理器（分别是 `pnpm` 和 `npm`）在处理依赖安装、存储和优化方面有一些关键区别。\n\n### 1. **存储方式的区别**\n\n- **npm**：在每个项目的 `node_modules` 文件夹中分别存储其依赖。这意味着如果你有多个项目，它们共享相同的依赖库，这些依赖库的多个副本将在你的文件系统中的每个项目内分别存储。这样做会占用更多的磁盘空间。\n\n- **pnpm**：采用一种称为**内容寻址文件系统**的方式来存储依赖。所有项目的依赖被存储在一个共享的位置，各个项目中的 `node_modules` 目录通过硬链接（hard links）或符号链接（symlinks）指向这个共享位置。该方法有效地减少了磁盘空间的占用，并加快了依赖的安装速度。\n\n### 2. **性能与速度**\n\n- **pnpm**：由于对依赖进行了有效的复用，并且使用硬链接来减少磁盘上的副本数量，通常可以提供比 `npm` 更快的安装速度。\n\n- **npm**：近几个大版本中也进行了许多性能改进，但在多个项目中共享相同依赖时，它可能仍然比 `pnpm` 更慢，尤其是在首次安装依赖时。\n\n### 3. **依赖平面结构 vs. 嵌套结构**\n\n- **npm**：自版本 3 以后，默认创建扁平的 `node_modules` 结构（尽可能），这样做是为了避免 Windows 系统中路径过长的问题。但在必要时， `npm` 仍然会创建嵌套的 `node_modules` 目录结构，以解决依赖冲突。\n\n- **pnpm**：通过使用符号链接，`pnpm` 维护了一个严格的嵌套依赖结构，更接近每个包的 `package.json` 文件所声明的依赖树形态。这提供了更高的一致性和在某些情况下更好的包隔离性。\n\n### 4. **依赖隔离与安全性**\n\n- **pnpm**：更好地隔离了依赖，每个包只能访问其在 `package.json` 中声明的依赖。这一特性增强了项目的安全性，因为它阻止了未声明的依赖被意外引入的情况。\n\n- **npm**：虽然 `npm` 也遵循 `package.json` 中的声明，但其扁平化的 `node_modules` 结构有时可能会容易地让包访问到未明确声明的依赖。\n\n### 5. **命令行界面（CLI）和配置**\n\n- 这两个工具的命令行界面（CLI）和配置都非常直观且类似，但它们的某些命令和选项可能会有细微差别。`pnpm` 为了优化性能和安全性引入了一些特有的命令和配置选项。\n\n总的来说，`pnpm` 在多项目管理、磁盘空间和安装速度方面提供了优于 `npm` 的性能和利益。对于新项目或在寻求性能优化的既存项目，考虑试用 `pnpm` 可能是个不错的选择。\n",{"_54":904,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/889/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/889/timeline",{"_54":907,"_56":57,"_58":908,"_60":909,"_62":910,"_64":911,"_66":912,"_68":913,"_70":914,"_72":915,"_74":916,"_107":917,"_120":121,"_122":26,"_123":-5,"_124":920,"_126":921,"_148":141,"_142":934,"_144":935,"_147":-5,"_151":152,"_153":936,"_158":-5,"_159":937,"_161":938,"_173":940,"_175":-5,"_176":-5,"_177":178},"https://api.github.com/repos/pro-collection/interview-question/issues/888","https://api.github.com/repos/pro-collection/interview-question/issues/888/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/888/comments","https://api.github.com/repos/pro-collection/interview-question/issues/888/events","https://github.com/pro-collection/interview-question/issues/888",2529844180,"I_kwDOJGDC6c6WylvU",888,"monorepo 工程有哪些工具架构，该如何选型【热度: 450】",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},[918,919],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":193,"_68":194,"_54":195,"_113":196,"_115":197,"_117":26,"_118":198},[],{"_54":922,"_64":923,"_58":924,"_66":925,"_68":926,"_70":927,"_72":928,"_118":929,"_136":930,"_138":931,"_140":141,"_120":121,"_142":932,"_144":933,"_146":-5,"_147":-5},"https://api.github.com/repos/pro-collection/interview-question/milestones/4","https://github.com/pro-collection/interview-question/milestone/4","https://api.github.com/repos/pro-collection/interview-question/milestones/4/labels",9124550,"MI_kwDOJGDC6c4AizrG",4,"资深","资深级别面试问题",{"_76":77,"_66":78,"_68":79,"_80":81,"_82":23,"_54":83,"_64":84,"_85":86,"_87":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_62":99,"_100":101,"_102":103,"_104":105,"_106":26},48,"2023-03-06T15:00:45Z","2024-10-07T08:15:55Z","2024-09-17T02:31:47Z","2024-09-17T02:40:09Z",{"_155":141,"_156":141,"_157":141},"**关键词**：monorepo 技术选项\n\n### 工具推荐\n\n| 工具 | **Turborepo** | **Rush** | **Nx** | **Lerna** | **Pnpm Workspace** |\n| -------- | ------------- | -------- | ------ | --------- | ------------------ |\n| 依赖管理 | ❌ | ✅ | ❌ | ❌ | ✅ |\n| 版本管理 | ❌ | ✅ | ❌ | ✅ | ❌ |\n| 增量构建 | ✅ | ✅ | ✅ | ❌ | ❌ |\n| 插件扩展 | ✅ | ✅ | ✅ | ❌ | ❌ |\n| 云端缓存 | ✅ | ✅ | ✅ | ❌ | ❌ |\n| Stars | 20.4K | 4.9K | 17K | 34.3K | 22.7K |\n\n![img](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d85551b9ce50496d8403956b571c4635~tplv-k3u1fbpfcp-jj-mark:3024:0:0:0:q75.awebp#?w=2610&h=1020&s=64366&e=webp&b=fdfdfd)\n\n### 工具选型\n\n选择合适的 Monorepo 管理工具对于确保项目的顺利进行是至关重要的。Monorepo 管理工具可以帮助你高效地管理项目依赖、统一代码风格、简化开发流程等。在进行 Monorepo 工具选型时，需要考虑几个重要的因素：\n\n#### 1. **技术栈的兼容性**\n\n- **Lerna**：与任何技术栈兼容性都很好，特别是与前端项目协同工作时。它对 NPM 和 Yarn 都有良好支持，适用于需要独立版本管理或频繁发布的项目。\n- **Yarn Workspaces**：特别适合使用 Yarn 作为包管理器的 JavaScript 或 TypeScript 项目。它非常适合团队中包之间有很多交叉依赖的情形。\n- **Nx**：支持多种前端和后端框架，如 Angular、React、NestJS 等。如果项目采用多技术栈，Nx 提供了一套完整的解决方案，包含了构建、测试和 linting 等一站式服务。\n- **Rush**：同样适用于大型项目，兼容任何 NPM 包管理器，如 NPM、Yarn、pnpm。Rush 提供了灵活的版本控制策略，非常适合需要精细控制包版本策略的场景。\n- **pnpm Workspaces**：具有高效的节点模块解析机制，非常注重节省磁盘空间及速度优化。如果磁盘空间和安装速度是关键考虑因素，pnpm 会是一个不错的选择。\n\n#### 2. **项目的规模和复杂度**\n\n- 对于大型或复杂项目，**Nx** 和 **Rush** 提供了更多的高级特性，比如增量构建、依赖图可视化等，可以有效提升大团队的开发效率。\n- 对于中小型项目，**Lerna**、**Yarn Workspaces** 或 **pnpm Workspaces** 可能更易上手，配置和管理也较为简单。\n\n#### 3. **构建、测试和部署的需求**\n\n- 如果项目需要复杂的构建、测试流程，**Nx** 提供了一些很好的工具来优化这一过程。Nx 可以智能地只重新构建受影响的项目，节省 CI/CD 的时间和资源。\n- **Rush** 强调在大型仓库中提供稳定而灵活的版本策略和发布管理，对于需要精细控制不同环境部署的项目非常有用。\n\n#### 4. **团队协作和代码共享的便利性**\n\n- 所有这些工具都支持代码共享和重用，但是**Nx** 和 **Rush** 在支持大型团队和多项目协作方面有一些额外的优势，如更智能的依赖管理和版本控制。\n\n#### 5. **社区支持和文档**\n\n- **Nx** 拥有强大的社区支持和丰富的文档、教程，非常适合于新技术栈的团队。\n- **Lerna** 和 **Yarn Workspaces** 受众广泛，网上有很多资源和案例，学习曲线相对平缓。\n\n#### 推荐策略\n\n如果你的项目非常关注于构建效率和对多种技术栈的支持，**Nx** 是非常好的选择。如果你更关心包的独立发布和版本管理，**Lerna** 和 **Rush** 可以满足你的需求。而对于那些偏好 Yarn 并且注重依赖管理的项目来说，**Yarn Workspaces** 提供了一套简单直接的解决方案。如果磁盘空间和安装速度是你的主要考虑，不妨试试 **pnpm Workspaces**。\n",{"_54":939,"_164":141,"_165":141,"_166":141,"_167":141,"_168":141,"_169":141,"_170":141,"_171":141,"_172":141},"https://api.github.com/repos/pro-collection/interview-question/issues/888/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/888/timeline","pagination",{"_943":178,"_155":944},"value",6,"actionData","errors"]