[{"_1":2,"_953":-5,"_954":-5},"loaderData",{"_3":4,"_49":50},"root",{"_5":6},"clerkState",{"_7":8},"__internal_clerk_state",{"_9":10,"_20":21,"_22":23,"_24":23,"_25":26,"_27":23,"_28":23,"_29":23,"_30":23,"_31":23,"_32":23,"_33":23,"_34":23,"_35":36,"_45":23,"_46":23,"_47":26,"_48":26},"__clerk_ssr_state",{"_11":-5,"_12":-5,"_13":-5,"_14":-5,"_15":-5,"_16":-5,"_17":-5,"_18":-5,"_19":-5},"sessionClaims","sessionId","userId","actor","orgId","orgRole","orgSlug","orgPermissions","factorVerificationAge","__publishableKey","pk_live_Y2xlcmsucXVlc3Rpb25zLnZpc3VhbGl6ZWl0LmFwcCQ","__proxyUrl","","__domain","__isSatellite",false,"__signInUrl","__signUpUrl","__afterSignInUrl","__afterSignUpUrl","__signInForceRedirectUrl","__signUpForceRedirectUrl","__signInFallbackRedirectUrl","__signUpFallbackRedirectUrl","__clerk_debug",{"_37":26,"_38":23,"_39":40,"_41":23,"_42":21,"_43":26,"_44":23},"isSignedIn","proxyUrl","reason","session-token-and-uat-missing","message","publishableKey","isSatellite","domain","__clerkJSUrl","__clerkJSVersion","__telemetryDisabled","__telemetryDebug","routes/_index",{"_51":52,"_948":949},"questions",[53,186,224,259,282,305,328,351,374,397,420,444,467,490,514,537,560,588,616,639,667,691,714,738,761,785,809,833,856,879,902,925],{"_54":55,"_56":57,"_58":59,"_60":61,"_62":63,"_64":65,"_66":67,"_68":69,"_70":71,"_72":73,"_74":75,"_107":108,"_127":128,"_129":26,"_130":-5,"_131":132,"_133":134,"_155":148,"_149":156,"_151":157,"_154":-5,"_158":159,"_160":161,"_165":-5,"_166":167,"_168":169,"_180":181,"_182":-5,"_183":-5,"_184":185},"url","https://api.github.com/repos/pro-collection/interview-question/issues/341","repository_url","https://api.github.com/repos/pro-collection/interview-question","labels_url","https://api.github.com/repos/pro-collection/interview-question/issues/341/labels{/name}","comments_url","https://api.github.com/repos/pro-collection/interview-question/issues/341/comments","events_url","https://api.github.com/repos/pro-collection/interview-question/issues/341/events","html_url","https://github.com/pro-collection/interview-question/issues/341","id",1698600860,"node_id","I_kwDOJGDC6c5lPpec","number",341,"title","npm script 生命周期有哪些?【热度: 519】","user",{"_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},"login","yanlele",22188674,"MDQ6VXNlcjIyMTg4Njc0","avatar_url","https://avatars.githubusercontent.com/u/22188674?v=4","gravatar_id","https://api.github.com/users/yanlele","https://github.com/yanlele","followers_url","https://api.github.com/users/yanlele/followers","following_url","https://api.github.com/users/yanlele/following{/other_user}","gists_url","https://api.github.com/users/yanlele/gists{/gist_id}","starred_url","https://api.github.com/users/yanlele/starred{/owner}{/repo}","subscriptions_url","https://api.github.com/users/yanlele/subscriptions","organizations_url","https://api.github.com/users/yanlele/orgs","repos_url","https://api.github.com/users/yanlele/repos","https://api.github.com/users/yanlele/events{/privacy}","received_events_url","https://api.github.com/users/yanlele/received_events","type","User","user_view_type","public","site_admin","labels",[109,120],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},5284642729,"LA_kwDOJGDC6c8AAAABOv0_qQ","https://api.github.com/repos/pro-collection/interview-question/labels/%E5%B7%A5%E7%A8%8B%E5%8C%96","name","工程化","color","1d76db","default","description","web 项目工程化",{"_66":121,"_68":122,"_54":123,"_113":124,"_115":125,"_117":26,"_118":126},5326133419,"LA_kwDOJGDC6c8AAAABPXZYqw","https://api.github.com/repos/pro-collection/interview-question/labels/%E5%B0%8F%E7%B1%B3","小米","ededed","公司标签","state","open","locked","assignee","assignees",[],"milestone",{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":144,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-5},"https://api.github.com/repos/pro-collection/interview-question/milestones/3","https://github.com/pro-collection/interview-question/milestone/3","https://api.github.com/repos/pro-collection/interview-question/milestones/3/labels",9124547,"MI_kwDOJGDC6c4AizrD",3,"高","高级别面试问题","creator",{"_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},"open_issues",425,"closed_issues",0,"created_at","2023-03-06T15:00:27Z","updated_at","2025-02-10T16:49:33Z","due_on","closed_at","comments","2023-05-06T12:00:10Z","2023-05-06T12:10:45Z","author_association","MEMBER","sub_issues_summary",{"_162":148,"_163":148,"_164":148},"total","completed","percent_completed","active_lock_reason","body","**关键词**：npm 生命周期、script 生命周期\n\n\n### 安装和卸载\n\n| 脚本名称 | 阶段 | 描述 | 执行时机 |\n|-----------------|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------|\n| preinstall | pre | 在 npm install 执行前运行，用于执行一些安装前的准备工作，例如检查依赖项或设置环境变量。 | 安装前 |\n| install, postinstall | install | 在模块安装后执行，通常用于构建项目或者为其生成某些必须的文件，例如安装完毕后自动编译 TypeScript、ES6 等。 | 安装后 |\n| preuninstall | pre | 在 npm uninstall 执行前运行，用于执行一些卸载前的准备工作。 | 卸载前 |\n| uninstall | post | 在 npm uninstall 执行后运行，用于清理卸载后的一些操作。 | 卸载后 |\n| postuninstall | post | 在 npm uninstall 执行后运行，用于执行一些卸载后的操作。 | 卸载后 |\n\n### 发布和更新版本\n\n| 脚本名称 | 阶段 | 描述 | 执行时机 |\n|-----------------|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------|\n| prepublish | pre | 在 publish（npm发布）执行前，运行 npm pack。 | 发布前 |\n| prepare | pre | 在包被发布前或安装前执行，可以用来设置编译或验证文件的操作。 | 发布前、安装前 |\n| prepublishOnly | pre | 在 npm publish 执行前运行，用于确保在 publish 命令执行时不会意外发布不必要的文件。 | 发布前 |\n| prepack | pre | 在 npm pack（打包命令）执行前运行，用于执行一些打包前的准备工作。 | 打包前 |\n| postpack | post | 在 npm pack 执行后运行，用于清理和重置打包相关的操作。 | 打包后 |\n| publish | post | 在包被成功发布后执行。 | 发布后 |\n| postpublish | post | 在包被成功发布后执行，用于执行一些发布后的操作。 | 发布后 |\n| preversion | pre | 在项目版本号更新（npm version）之前执行。 | 更新版本号前 |\n| version | post | 在 npm version 执行后执行，用于执行一些版本更新后的操作。 | 更新版本号后 |\n| postversion | post | 在项目版本号更新（npm version）之后执行。 | 更新版本号后 |\n\n### 测试和运行\n\n| 脚本名称 | 阶段 | 描述 | 执行时机 |\n|-----------------|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------|\n| pretest | pre | 在 npm test 执行前执行，用于执行某些测试前的准备工作。 | 测试前 |\n| test | test | 执行 npm run test 命令时执行。通常用于执行单元测试，并返回任何错误状态。 | 默认测试阶段 |\n| posttest | post | 在 npm test 执行后执行，用于执行某些测试后的操作。 | 测试后 |\n| prestart | pre | 在 npm start 执行前运行，用于执行某些启动进程前的准备工作。 | 启动前 |\n| start | start | 执行 npm start 命令时执行，通常用于启动 Web 服务器、Node 服务器、实时编译器等。 | 默认启动阶段 |\n| poststart | post | 在 npm start 执行后执行，用于执行某些启动进程后的操作。 | 启动后 |\n| prerestart | pre | 在 npm restart 执行前执行，用于执行一些重新启动进程前的准备工作。 | 重新启动前 |\n| restart | stop/start | 执行 npm restart 命令时执行，通常用于停止正在运行的 Node 服务器、Web 服务器等，然后以更新的源码重新启动服务。 | 默认重新启动阶段，但是该命令会触发停止和启动两个标准阶段 |\n| postrestart | post | 在 npm restart 执行后执行，用于执行一些重新启动进程后的操作。 | 重新启动后 |\n\n### 其他生命周期\n\n| 脚本名称 | 阶段 | 描述 | 执行时机 |\n|-----------------|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------|\n| prestop | pre | 在 npm stop 执行前运行，用于执行某些停止进程前的准备工作。 | 停止前 |\n| stop | stop | 执行 npm stop 命令时执行，通常用于停止正在运行的 Web 服务器、Node 服务器、实时编译器等。 | 默认停止阶段 |\n| poststop | post | 在 npm stop 执行后执行，用于执行某些停止进程后的操作。 | 停止后 |\n","reactions",{"_54":170,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/341/reactions","total_count","+1","-1","laugh","hooray","confused","heart","rocket","eyes","timeline_url","https://api.github.com/repos/pro-collection/interview-question/issues/341/timeline","performed_via_github_app","state_reason","score",1,{"_54":187,"_56":57,"_58":188,"_60":189,"_62":190,"_64":191,"_66":192,"_68":193,"_70":194,"_72":195,"_74":196,"_107":197,"_127":128,"_129":26,"_130":-5,"_131":204,"_133":205,"_155":148,"_149":218,"_151":218,"_154":-5,"_158":159,"_160":219,"_165":-5,"_166":220,"_168":221,"_180":223,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/316","https://api.github.com/repos/pro-collection/interview-question/issues/316/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/316/comments","https://api.github.com/repos/pro-collection/interview-question/issues/316/events","https://github.com/pro-collection/interview-question/issues/316",1685254388,"I_kwDOJGDC6c5kcvD0",316,"npm 包管理了解多少？【热度: 1,321】",{"_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},[198,199],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":200,"_68":201,"_54":202,"_113":203,"_115":125,"_117":26,"_118":126},5312726360,"LA_kwDOJGDC6c8AAAABPKnFWA","https://api.github.com/repos/pro-collection/interview-question/labels/%E8%85%BE%E8%AE%AF","腾讯",[],{"_54":206,"_64":207,"_58":208,"_66":209,"_68":210,"_70":211,"_72":212,"_118":213,"_143":214,"_145":215,"_147":148,"_127":128,"_149":216,"_151":217,"_153":-5,"_154":-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","2023-04-26T15:28:50Z",{"_162":148,"_163":148,"_164":148},"**关键词**：npm 依赖管理、npm 包管理、npm 缓存\n\n**npm 是如何进行依赖管理的？**\n\nnpm 是通过 package.json 文件来进行依赖管理的。当在项目中使用第三方库时，我们可以在 package.json 中添加对应的依赖项及版本号，npm 会根据 package.json 中的依赖关系，自动安装相应的依赖包及其依赖项。当我们执行 npm install 命令时，npm 会自动根据 package.json 中的依赖信息进行依赖包的安装。\n\nnpm 的依赖管理还涉及到依赖的版本控制，可以在 package.json 中指定对应的版本号，常见的版本号控制符号有：\n\n- `^（caret）`：匹配到次要版本号（第二个数字）的最新版本。例如，^1.2.3 表示安装 1.2.x 的最新版本（除了 1.3.0）。\n- `~（tilde）`：匹配到修订版本号（第三个数字）的最新版本。例如，~1.2.3 表示安装 1.2.3 到 1.2.x 的最新版本（除了 1.3.0）。\n- `*`：匹配到最新的版本。\n- `>=`：匹配到大于或等于指定版本的最新版本。\n- `<、<=、>`：匹配到小于、小于等于或大于指定版本的最新版本。\n\n在 npm 的依赖管理中，还有两种类型的依赖关系：生产依赖和开发依赖。生产依赖是指在应用程序运行时必须要加载的依赖，开发依赖是指在应用程序开发过程中使用的依赖。在 package.json 中，生产依赖使用 dependencies 字段，开发依赖使用 devDependencies 字段。这样可以让项目更加清晰地管理其依赖关系。\n\n\n**npm 有缓存包的能力吗？**\n\nnpm有缓存包的能力。当你第一次使用npm安装一个包时，npm会自动将该包缓存在本地。这样，当你下次需要安装相同版本的该包时，npm就不必重新从网络上下载该包，而是直接使用缓存中的包。这样可以提高包的下载速度，节省网络带宽。\n\nnpm的缓存位于本地文件系统中的一个隐藏目录。默认情况下，缓存位于当前用户的主目录下的.npm目录中。你可以使用以下命令查看npm缓存的路径：\n```shell\nnpm config get cache\n```\n\n你也可以通过npm cache命令来管理npm缓存，例如清空缓存：\n```shell\nnpm cache clean\n```\n\n或者查看缓存的统计信息：\n```shell\nnpm cache ls\n```\n\n\n**npm 是如何使用缓存中的包的？**\n\n使用缓存中的包可以通过以下两种方式实现：\n\n- `使用 npm ci 命令`\nnpm ci 命令会首先检查 package-lock.json 或 npm-shrinkwrap.json 文件，以确保安装的依赖与锁定的版本一致。然后，它会在 node_modules 目录下安装依赖，如果缓存中存在符合要求的包，npm ci 会直接从缓存中复制到 node_modules 目录下，而不需要重新下载和编译。\n\n- `手动指定缓存路径`\n如果需要手动使用缓存中的包，可以在 npm install 命令中指定缓存路径，例如：\n```shell\nnpm install --cache /path/to/npm-cache\n```\n然后，执行 npm install 命令时，npm 会尝试从指定的缓存路径中获取包，如果找到匹配的包，就会直接复制到 node_modules 目录下。\n\n需要注意的是，手动指定缓存路径的方式可能会导致不同的项目之间共用缓存，因此需要确保缓存路径的唯一性。\n",{"_54":222,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/316/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/316/timeline",{"_54":225,"_56":57,"_58":226,"_60":227,"_62":228,"_64":229,"_66":230,"_68":231,"_70":232,"_72":233,"_74":234,"_107":235,"_127":128,"_129":26,"_130":-5,"_131":238,"_133":239,"_155":148,"_149":252,"_151":253,"_154":-5,"_158":159,"_160":254,"_165":-5,"_166":255,"_168":256,"_180":258,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/315","https://api.github.com/repos/pro-collection/interview-question/issues/315/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/315/comments","https://api.github.com/repos/pro-collection/interview-question/issues/315/events","https://github.com/pro-collection/interview-question/issues/315",1685233710,"I_kwDOJGDC6c5kcqAu",315,"npx 了解多少？【热度: 290】",{"_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},[236,237],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":121,"_68":122,"_54":123,"_113":124,"_115":125,"_117":26,"_118":126},[],{"_54":240,"_64":241,"_58":242,"_66":243,"_68":244,"_70":245,"_72":246,"_118":247,"_143":248,"_145":249,"_147":148,"_127":128,"_149":250,"_151":251,"_153":-5,"_154":-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","2023-04-26T15:15:58Z","2023-04-26T15:16:44Z",{"_162":148,"_163":148,"_164":148},"**关键词**：npx 原理、npx 作用、npx 执行\r\n\r\n\r\n**npx 是什么**\r\n\r\nnpx是一个由Node.js官方提供的用于快速执行npm包中的可执行文件的工具。它可以帮助我们在不全局安装某些包的情况下，直接运行该包提供的命令行工具。npx会在执行时，检查本地项目中是否安装了对应的依赖，如果没有安装则会自动下载安装，并执行命令。如果本地已经存在该依赖，则直接执行命令。\r\n\r\n使用npx时，可以在命令行中输入要执行的包名加上其参数，例如：\r\n```shell\r\nnpx create-react-app my-app\r\n```\r\n以上命令会在本地下载并运行create-react-app包中的可执行文件，创建一个名为my-app的React应用程序。\r\n\r\n\r\n**npx 会把远端的包下载到本地吗?**\r\n\r\nnpx 不会像 npm 或 yarn 一样将包下载到本地的 node_modules 目录中。相反，它会在执行命令时，在本地缓存中寻找并下载包，然后执行该包中的命令。这样可以避免在开发过程中在全局安装大量的包，同时也可以确保使用的是最新版本的包。\r\n\r\n\r\n**npx 执行完成之后，下载的包是否会被删除？**\r\n\r\n是的，npx会在执行完命令后删除下载的包。这是因为npx会在执行命令之前，将需要执行的包下载到一个临时目录中，并在执行完毕后删除该目录。这样可以避免在本地留下不必要的依赖包。如果需要保留依赖包，可以使用--no-cleanup选项来禁止删除下载的包。\r\n",{"_54":257,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/315/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/315/timeline",{"_54":260,"_56":57,"_58":261,"_60":262,"_62":263,"_64":264,"_66":265,"_68":266,"_70":267,"_72":268,"_74":269,"_107":270,"_127":128,"_129":26,"_130":-5,"_131":273,"_133":274,"_155":148,"_149":276,"_151":276,"_154":-5,"_158":159,"_160":277,"_165":-5,"_166":278,"_168":279,"_180":281,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/314","https://api.github.com/repos/pro-collection/interview-question/issues/314/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/314/comments","https://api.github.com/repos/pro-collection/interview-question/issues/314/events","https://github.com/pro-collection/interview-question/issues/314",1685215387,"I_kwDOJGDC6c5kclib",314,"npm lock 文件了解多少？【热度: 258】",{"_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},[271,272],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":121,"_68":122,"_54":123,"_113":124,"_115":125,"_117":26,"_118":126},[],{"_54":240,"_64":241,"_58":242,"_66":243,"_68":244,"_70":245,"_72":246,"_118":247,"_143":275,"_145":249,"_147":148,"_127":128,"_149":250,"_151":251,"_153":-5,"_154":-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},"2023-04-26T15:05:23Z",{"_162":148,"_163":148,"_164":148},"**关键词**：npm lock 原理、npm lock 实现、npm lock 作用\n\n**作用**\n\nnpm lock 文件（如 package-lock.json 或 yarn.lock）的作用是确保在不同机器上或在不同时间安装相同的依赖包时，获得相同的版本，以避免由于版本不一致而产生的问题。在安装依赖包时，npm lock 文件会锁定当前的依赖树，并记录每个依赖包的确切版本号和依赖关系。这样，在重新安装依赖包时，npm 将使用 lock 文件中记录的版本和依赖关系来安装依赖包，而不是根据 package.json 文件中的符号依赖去解析版本。这确保了依赖包版本的一致性。\n\n**生成原理**\n\n生成 npm lock 文件的原理如下：\n\n- 当我们使用 npm install 或 npm ci 安装依赖包时，npm 会检查项目中的 `package.json` 文件，并根据其中的依赖包信息，生成一个 `node_modules` 目录用来存储这些依赖包。\n\n- 在生成 node_modules 目录时，npm 会生成一个 `npm-shrinkwrap.json` 或 `package-lock.json` 文件，用来记录所有已经安装的依赖包的精确版本信息和依赖关系。这些信息是根据 `package.json` 文件和 `node_modules` 目录中实际安装的依赖包信息计算出来的。\n\n- 在以后的安装过程中，npm 会先检查是否存在 `npm-shrinkwrap.json` 或 `package-lock.json` 文件，如果存在，就使用其中的依赖包版本信息来安装依赖包，而不是根据 `package.json` 文件中的信息重新计算依赖包版本。这样就可以确保每次安装时都使用相同的依赖包版本，避免了版本不一致导致的问题。\n\n\n**npm-shrinkwrap.json 是什么文件？**\n\n`npm-shrinkwrap.json` 文件是 Node.js 包管理工具 npm 生成的一份锁定文件，用于锁定项目依赖包的版本，确保团队成员在使用同一版本的依赖包，以避免在不同环境下因版本不一致而导致的问题。\n\n与 `package-lock.json` 文件类似，`npm-shrinkwrap.json` 文件可以在项目中确保依赖包版本的一致性，但它与 `package-lock.json` 文件不同之处在于，它能够锁定所有的依赖包版本，包括间接依赖的包版本，而 `package-lock.json` 文件只会锁定直接依赖包的版本。\n\n同时，使用 `npm-shrinkwrap.json` 文件也需要注意，在项目开发过程中，如果需要升级依赖包版本，需要手动更新 `npm-shrinkwrap.json` 文件中的对应依赖包版本号。\n\n**如何启用 npm-shrinkwrap.json**\n\n在项目根目录下使用以下命令可以生成 `npm-shrinkwrap.json` 文件：\n```\nnpm shrinkwrap\n```\n\n如果需要在安装新的包时同时更新 `npm-shrinkwrap.json` 文件，可以使用以下命令：\n```\nnpm shrinkwrap --dev\n```\n\n这个命令会把 devDependencies 也包括在生成的 npm-shrinkwrap.json 文件中。\n",{"_54":280,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/314/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/314/timeline",{"_54":283,"_56":57,"_58":284,"_60":285,"_62":286,"_64":287,"_66":288,"_68":289,"_70":290,"_72":291,"_74":292,"_107":293,"_127":128,"_129":26,"_130":-5,"_131":295,"_133":296,"_155":245,"_149":298,"_151":299,"_154":-5,"_158":159,"_160":300,"_165":-5,"_166":301,"_168":302,"_180":304,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/313","https://api.github.com/repos/pro-collection/interview-question/issues/313/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/313/comments","https://api.github.com/repos/pro-collection/interview-question/issues/313/events","https://github.com/pro-collection/interview-question/issues/313",1685169027,"I_kwDOJGDC6c5kcaOD",313,"语义化版本 SemVer（Semantic Versioning）了解多少？",{"_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},[294],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":240,"_64":241,"_58":242,"_66":243,"_68":244,"_70":245,"_72":246,"_118":247,"_143":297,"_145":249,"_147":148,"_127":128,"_149":250,"_151":251,"_153":-5,"_154":-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},"2023-04-26T14:40:53Z","2023-09-12T14:13:38Z",{"_162":148,"_163":148,"_164":148},"Semantic Versioning（语义化版本）是一种为软件组件定义版本号的规范。它使用`“major.minor.patch”`的格式来表示版本号。其中：\r\n\r\n- Major（主版本号）：当你做了不兼容的 API 修改时，你需要更新主版本号。\r\n- Minor（次版本号）：当你做了向下兼容的功能性新增时，你需要更新次版本号。\r\n- Patch（修订号）：当你做了向下兼容的问题修正时，你需要更新修订号。\r\n\r\nSemantic Versioning 的目的是为了让软件版本号的变化具有可读性和可预测性，这样用户就可以通过版本号来了解软件包的更新内容和影响。\r\n\r\n**版本更新**\r\n\r\n在升级版本时，常常使用一些符号来指定允许升级的范围，其中包括 ^ 和 ~ 等。\r\n\r\n- ^ 表示向后兼容地升级版本号，只允许升级到次版本号或修订版本号，不允许升级到主版本号。\r\n- ~ 表示只允许升级到修订版本号，不允许升级到次版本号或主版本号。\r\n\r\n例如，对于版本号为 1.2.3：\r\n\r\n- ^1.2.3 允许升级到 1.2.4、1.3.0 等修订号或次版号的版本，但不允许升级到 2.0.0。\r\n- ~1.2.3 只允许升级到 1.2.4、1.2.5 等修订版本号的版本，但不允许升级到 1.3.0、2.0.0 等更高的版本。\r\n",{"_54":303,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/313/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/313/timeline",{"_54":306,"_56":57,"_58":307,"_60":308,"_62":309,"_64":310,"_66":311,"_68":312,"_70":313,"_72":314,"_74":315,"_107":316,"_127":128,"_129":26,"_130":-5,"_131":318,"_133":319,"_155":148,"_149":321,"_151":322,"_154":-5,"_158":159,"_160":323,"_165":-5,"_166":324,"_168":325,"_180":327,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/312","https://api.github.com/repos/pro-collection/interview-question/issues/312/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/312/comments","https://api.github.com/repos/pro-collection/interview-question/issues/312/events","https://github.com/pro-collection/interview-question/issues/312",1685133087,"I_kwDOJGDC6c5kcRcf",312,"npm script 了解多少？【热度: 364】",{"_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},[317],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":240,"_64":241,"_58":242,"_66":243,"_68":244,"_70":245,"_72":246,"_118":247,"_143":320,"_145":249,"_147":148,"_127":128,"_149":250,"_151":251,"_153":-5,"_154":-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},"2023-04-26T14:20:39Z","2023-04-26T14:23:07Z",{"_162":148,"_163":148,"_164":148},"### 什么是 npm script\r\n\r\nnpm 允许在package.json文件里面，使用scripts字段定义脚本命令。\r\n\r\n```awk\r\n{\r\n // ...\r\n \"scripts\": {\r\n \"build\": \"node build.js\"\r\n }\r\n}\r\n```\r\n\r\n上面代码是`package.json`文件的一个片段，里面的scripts字段是一个对象。它的每一个属性，对应一段脚本。比如，build命令对应的脚本是`node build.js`。\r\n\r\n命令行下使用`npm run`命令，就可以执行这段脚本。\r\n\r\n```crmsh\r\n\r\n$ npm run build\r\n# 等同于执行\r\n$ node build.js\r\n```\r\n\r\n这些定义在`package.json`里面的脚本，就称为npm脚本。它的优点很多。\r\n\r\n* 项目的相关脚本，可以集中在一个地方。\r\n* 不同项目的脚本命令，只要功能相同，就可以有同样的对外接口。\r\n* 用户不需要知道怎么测试你的项目，只要运行npm run test即可。\r\n* 可以利用 npm 提供的很多辅助功能。\r\n\r\n查看当前项目的所有 npm 脚本命令，可以使用不带任何参数的`npm run`命令。\r\n\r\n```applescript\r\n$ npm run\r\n```\r\n\r\n---\r\n\r\n### 原理\r\n\r\nnpm run 实际上是 npm run-script 命令的简写\r\n\r\n* 从 package.json 文件中读取 scripts 对象里面的全部配置；\r\n* 以传给 npm run 的第一个参数作为键，如dev，在 scripts 对象里面获取对应的值作为接下来要执行的命令，如果没找到直接报错；\r\n\r\n每当执行npm run，就会自动新建一个 Shell，在这个 Shell 里面执行指定的脚本命令。因此，只要是 Shell（一般是 Bash）可以运行的命令，就可以写在 npm 脚本里面。\r\n\r\n比较特别的是，npm run新建的这个 Shell，会将当前目录的node\\_modules/.bin子目录加入PATH变量，执行结束后，再将PATH变量恢复原样。\r\n\r\n这意味着，当前目录的node\\_modules/.bin子目录里面的所有脚本，都可以直接用脚本名调用，而不必加上路径。比如，当前项目的依赖里面有 Mocha，只要直接写mocha test就可以了。\r\n\r\n```json\r\n\"test\": \"mocha test\"\r\n```\r\n\r\n### 通配符\r\n\r\n由于 npm 脚本就是 Shell 脚本，因为可以使用 Shell 通配符。\r\n\r\n```json\r\n\"lint\": \"jshint *.js\"\r\n\"lint\": \"jshint **/*.js\"\r\n```\r\n\r\n上面代码中，\\*表示任意文件名，\\*\\*表示任意一层子目录。\r\n\r\n如果要将通配符传入原始命令，防止被 Shell 转义，要将星号转义。\r\n\r\n```json\r\n\"test\": \"tap test/\\*.js\"\r\n```\r\n\r\n---\r\n\r\n### 传参\r\n\r\n给 npm script 传递参数给 npm script 传递参数 eslint 内置了代码风格自动修复模式，只需给它传入 --fix 参数即可，在 scripts 中声明检查代码命令的同时你可能也需要声明修复代码的命令，面对这种需求，大多数同学可能会忍不住复制粘贴，如下：\r\n\r\n```diff\r\n@@ -5,6 +5,7 @@\r\n \"lint:js\": \"eslint *.js\",\r\n+ \"lint:js:fix\": \"eslint *.js --fix\",\r\n```\r\n\r\n在 lint:js 命令比较短的时候复制粘贴的方法简单粗暴有效，但是当 lint:js 命令变的很长之后，难免后续会有人改了 lint:js 而忘记修改 lint:js:fix（别问我为啥，我就是踩着坑过来的），更健壮的做法是，在运行 npm script 时给定额外的参数，代码修改如下：\r\n\r\n```diff\r\n@@ -5,6 +5,7 @@\r\n \"lint:js\": \"eslint *.js\",\r\n+ \"lint:js:fix\": \"npm run lint:js -- --fix\",\r\n```\r\n\r\n要格外注意 --fix 参数前面的 -- 分隔符，意指要给 npm run lint:js 实际指向的命令传递额外的参数。\r\n\r\n---\r\n\r\n### 注释\r\n\r\n```swift\r\n\"test\": \"# 运行所有代码检查和单元测试 . npm-run-all --parallel lint:* mocha\"\r\n```\r\n\r\n或者在单独的文件中可以自由给它添加注释\r\n\r\n---\r\n\r\n### 日志\r\n\r\n```dockerfile\r\nnpm run test --loglevel silent\r\nnpm run test --slient\r\nnpm run test -s\r\n```\r\n\r\n这个日志级别，只有命令本身的输出，读起来非常的简洁\r\n\r\n```dockerfile\r\nnpm run test --loglevel verbose\r\nnpm run test --verbose\r\nnpm run test -d\r\n```\r\n\r\n这个日志级别，详细打印出了每个步骤的参数、返回值\r\n\r\n---\r\n\r\n### 执行顺序\r\n\r\n如果 npm 脚本里面需要执行多个任务，那么需要明确它们的执行顺序。\r\n\r\n如果是并行执行（即同时的平行执行），可以使用&符号。\r\n\r\n```routeros\r\n$ npm run script1.js & npm run script2.js\r\n```\r\n\r\n如果是继发执行（即只有前一个任务成功，才执行下一个任务），可以使用&&符号。\r\n\r\n```routeros\r\n$ npm run script1.js && npm run script2.js\r\n```\r\n\r\n这两个符号是 Bash 的功能。此外，还可以使用 node 的任务管理模块：`npm-run-all`、`script-runner`\r\n\r\n```awk\r\n// 串行\r\n{\r\n- \"test\": \"npm run lint:js && npm run lint:css && npm run lint:json && npm run lint:markdown\"\r\n+ \"test\": \"npm-run-all lint:js lint:css lint:json lint:markdown\"\r\n },\r\n// 并行 --parallel\r\n{\r\n- \"test\": \"npm-run-all lint:*\"\r\n+ \"test\": \"npm-run-all --parallel lint:* mocha\"\r\n}\r\n```\r\n\r\n---\r\n\r\n### 默认值\r\n\r\n一般来说，npm 脚本由用户提供。但是，npm 对两个脚本提供了默认值。也就是说，这两个脚本不用定义，就可以直接使用。\r\n\r\n```1c\r\n\r\n\"start\": \"node server.js\"，\r\n\"install\": \"node-gyp rebuild\"\r\n```\r\n\r\n上面代码中，npm run start的默认值是node server.js，前提是项目根目录下有server.js这个脚本；npm run install的默认值是node-gyp rebuild，前提是项目根目录下有binding.gyp文件。\r\n\r\n---\r\n\r\n### 钩子\r\n\r\nnpm 脚本有pre和post两个钩子。举例来说，build脚本命令的钩子就是prebuild和postbuild。\r\n\r\n```smalltalk\r\n\"prebuild\": \"echo I run before the build script\",\r\n\"build\": \"cross-env NODE_ENV=production webpack\",\r\n\"postbuild\": \"echo I run after the build script\"\r\n```\r\n\r\n用户执行npm run build的时候，会自动按照下面的顺序执行。\r\n\r\nnpm run prebuild && npm run build && npm run postbuild 因此，可以在这两个钩子里面，完成一些准备工作和清理工作。下面是一个例子。\r\n\r\n```json\r\n\r\n\"clean\": \"rimraf ./dist && mkdir dist\",\r\n\"prebuild\": \"npm run clean\",\r\n\"build\": \"cross-env NODE_ENV=production webpack\"\r\n```\r\n\r\nnpm 默认提供下面这些钩子。\r\n\r\n```\r\nprepublish，postpublish\r\npreinstall，postinstall\r\npreuninstall，postuninstall\r\npreversion，postversion\r\npretest，posttest\r\nprestop，poststop\r\nprestart，poststart\r\nprerestart，postrestart\r\n```\r\n\r\n自定义的脚本命令也可以加上pre和post钩子。比如，myscript这个脚本命令，也有premyscript和postmyscript钩子。不过，双重的pre和post无效，比如prepretest和postposttest是无效的。\r\n\r\nnpm 提供一个npm\\_lifecycle\\_event变量，返回当前正在运行的脚本名称，比如pretest、test、posttest等等。所以，可以利用这个变量，在同一个脚本文件里面，为不同的npm scripts命令编写代码。请看下面的例子。\r\n\r\n```arcade\r\nconst TARGET = process.env.npm_lifecycle_event;\r\n\r\nif (TARGET === 'test') {\r\n console.log(`Running the test task!`);\r\n}\r\n\r\nif (TARGET === 'pretest') {\r\n console.log(`Running the pretest task!`);\r\n}\r\n\r\nif (TARGET === 'posttest') {\r\n console.log(`Running the posttest task!`);\r\n}\r\n```\r\n\r\n注意，prepublish这个钩子不仅会在npm publish命令之前运行，还会在npm install（不带任何参数）命令之前运行。这种行为很容易让用户感到困惑，所以 npm 4 引入了一个新的钩子prepare，行为等同于prepublish，而从 npm 5 开始，prepublish将只在npm publish命令之前运行。\r\n\r\n---\r\n\r\n### 简写形式\r\n\r\n四个常用的 npm 脚本有简写形式。\r\n\r\n```routeros\r\nnpm start是npm run start\r\nnpm stop是npm run stop的简写\r\nnpm test是npm run test的简写\r\nnpm restart是npm run stop && npm run restart && npm run start的简写\r\n```\r\n\r\nnpm start、npm stop和npm restart都比较好理解，而npm restart是一个复合命令，实际上会执行三个脚本命令：stop、restart、start。具体的执行顺序如下。\r\n\r\n```crmsh\r\nprerestart\r\nprestop\r\nstop\r\npoststop\r\nrestart\r\nprestart\r\nstart\r\npoststart\r\npostrestart\r\n```\r\n\r\n---\r\n\r\n### 变量\r\n\r\nnpm 脚本有一个非常强大的功能，就是可以使用 npm 的内部变量。\r\n\r\n运行 `npm run env`能拿到完整的变量列表\r\n\r\n使用`npm run env | grep npm_package | sort` 拿到部分排序后的环境变量\r\n\r\n通过npm\\_package\\_前缀，npm 脚本可以拿到package.json里面的字段。比如，下面是一个package.json。\r\n\r\n```json\r\n{\r\n \"name\": \"foo\",\r\n \"version\": \"1.2.5\",\r\n \"config\" : { \"port\" : \"8080\" },\r\n \"scripts\" : { \"start\" : \"node server.js\" }\r\n}\r\n```\r\n\r\n那么，变量npm\\_package\\_name返回foo，变量npm\\_package\\_version返回1.2.5。\r\n\r\n```arcade\r\n// view.js\r\nconsole.log(process.env.npm_package_name); // foo\r\nconsole.log(process.env.npm_package_version); // 1.2.5\r\n```\r\n\r\n上面代码中，我们通过环境变量process.env对象，拿到package.json的字段值。如果是 Bash 脚本，可以用`$npm_package_name`和`$npm_package_version`取到这两个值。\r\n\r\n`$npm_package_scripts_start`\r\n\r\n---\r\n\r\n### 结合 npm script 和 git-hooks\r\n\r\nGit 在代码版本管理之外，也提供了类似 npm script 里 pre、post 的钩子机制，叫做 Git Hooks，钩子机制能让我们在代码 commit、push 之前（后）做自己想做的事情。\r\n\r\n前端社区里有多种结合 npm script 和 git-hooks 的方案，比如 `pre-commit`、`husky`，相比较而言 husky 更好用，它支持更多的 Git Hooks 种类，再结合 `lint-staged` 使用就更好了。\r\n\r\n[了解更多](https://juejin.cn/post/6844903479283040269)\r\n\r\n---\r\n\r\n### 常用脚本示例\r\n\r\n```awk\r\n// 删除目录\r\n\"clean\": \"rimraf dist/*\",\r\n\r\n// 本地搭建一个 HTTP 服务\r\n\"serve\": \"http-server -p 9090 dist/\",\r\n\r\n// 打开浏览器\r\n\"open:dev\": \"opener http://localhost:9090\",\r\n\r\n// 实时刷新\r\n \"livereload\": \"live-reload --port 9091 dist/\",\r\n\r\n// 构建 HTML 文件\r\n\"build:html\": \"jade index.jade > dist/index.html\",\r\n\r\n// 只要 CSS 文件有变动，就重新执行构建\r\n\"watch:css\": \"watch 'npm run build:css' assets/styles/\",\r\n\r\n// 只要 HTML 文件有变动，就重新执行构建\r\n\"watch:html\": \"watch 'npm run build:html' assets/html\",\r\n\r\n// 部署到 Amazon S3\r\n\"deploy:prod\": \"s3-cli sync ./dist/ s3://example-com/prod-site/\",\r\n\r\n// 构建 favicon\r\n\"build:favicon\": \"node scripts/favicon.js\",\r\n```",{"_54":326,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/312/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/312/timeline",{"_54":329,"_56":57,"_58":330,"_60":331,"_62":332,"_64":333,"_66":334,"_68":335,"_70":336,"_72":337,"_74":338,"_107":339,"_127":128,"_129":26,"_130":-5,"_131":341,"_133":342,"_155":148,"_149":344,"_151":345,"_154":-5,"_158":159,"_160":346,"_165":-5,"_166":347,"_168":348,"_180":350,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/311","https://api.github.com/repos/pro-collection/interview-question/issues/311/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/311/comments","https://api.github.com/repos/pro-collection/interview-question/issues/311/events","https://github.com/pro-collection/interview-question/issues/311",1685119072,"I_kwDOJGDC6c5kcOBg",311,"package.json 配置了解多少？【热度: 747】",{"_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},[340],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":240,"_64":241,"_58":242,"_66":243,"_68":244,"_70":245,"_72":246,"_118":247,"_143":343,"_145":249,"_147":148,"_127":128,"_149":250,"_151":251,"_153":-5,"_154":-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},"2023-04-26T14:13:01Z","2023-04-26T14:13:02Z",{"_162":148,"_163":148,"_164":148},"`package.json`常见配置分类：\n\n- 描述配置\n\n- 文件配置\n\n- 脚本配置\n\n- 依赖配置\n\n- 发布配置\n\n- 系统配置\n\n- 第三方配置\n\n\n`package.json` 作用：存储一切与项目相关的配置，例如项目基本信息、外界访问项目的方式、项目内置脚本、项目依赖等。\n\n### 描述配置\n\n主要是项目的基本信息，包括名称，版本，描述，仓库，作者等，部分会展示在 npm 官网上。\n\n```js\n{\n \"name\": \"react\", // 项目名称 or npm包名\n \"version\": \"18.2.0\", // 版本号，开源项目的版本号通常遵循 semver 语义化规范\n \"repository\": {\n \"type\": \"git\",\n \"url\": \"https://github.com/facebook/react.git\",\n \"directory\": \"packages/react\"\n }, // 项目的仓库地址及版本控制信息\n \"description\": \"React is a JavaScript library for building user interfaces.\", // 项目描述 (展示于 npm 官网)\n \"keywords\": [\n \"ant\",\n \"component\",\n \"components\",\n \"design\",\n \"framework\",\n \"frontend\",\n \"react\",\n \"react-component\",\n \"ui\"\n ], // 项目技术关键词\n \"homepage\": \"https://reactjs.org/\", // 项目的主页链接，通常是项目 github 链接，项目官网或文档首页\n \"bugs\": \"https://github.com/vuejs/core/issues\", // 项目 bug 反馈地址，通常是 github issue 页面的链接\n \"author\": \"Li jiaxun\", // 作者信息\n \"private\": true, // 私有项目, 若为 true 则无法发布到 npm 官网上\n}\n```\n\n\n\n### 文件配置\n\n包括项目所包含的文件，以及入口等信息。\n\n```js\n{\n // 🔥@files: 指定需要跟随一起发布的内容，控制 npm 包的大小。\n // 发布时默认会包括 package.json，license，README 和main 字段里指定的文件。忽略 node_modules，lockfile 等文件。在此基础上，可以指定更多需要一起发布的内容。(单独的文件/整个文件夹/使用通配符匹配到的文件)\n // 一般情况下，files 里会指定构建出来的产物以及类型文件，而 src，test 等目录下的文件不需要跟随发布。\n \"files\": [\n \"filename.js\",\n \"directory/\",\n \"glob/*.{js,json}\"\n ],\n // 🔥@type: 'module' => 用 ESM 解释 .js 文件(此时访问 CJS 模块文件需要 .cjs 后缀)；反之同理。\n \"type\": \"module\",\n // 🔥@main: 项目入口文件。\n // if \"type: 'module'\" => 指向 ESM 模块规范的项目入口文件 else => CommonJS 模块规范的项目入口文件。\n \"main\": \"./index.cjs\",\n // @browser: web端项目入口文件路径。该路径下文件不允许在 server 端使用。\n \"browser\": \"./browser/index.js\",\n // 🔥@module: ESM 规范模块的项目入口文件。\n \"module\": \"./index.js\",\n // 🔥@exports: 配置不同环境对应的模块入口文件(优先级最高 > main)。\n // 作用1: 以别名形式封装包的子路径。\"import packageA/dist/css/index.css\" => \"import packageA/style\"\n // 作用2: 以 '.' 为别名时，表示模块主入口，可以看做是 \"mian\"/\"module\" 等字段功能的集合。\n // 作用3: 设置模块访问权限。exports 限制使用者不可以访问未在\"exports\"中定义的任何其他路径。\n // 作用4: 提供了项目(包)多入口访问的途径。例如下面的 './docs' 和 './components'\n \"exports\": {\n \".\": {\n \"require\": \"./index.cjs\",\n \"import\": \"./index.js\"\n },\n \"./docs\": {\n \"require\": \"./docs/index.cjs\",\n \"import\": \"./docs/index.js\"\n },\n \"./components\": {\n \"require\": \"./components/index.cjs\",\n \"import\": \"./components/index.js\"\n },\n \"./style\": \"./dist/css/index.css'\n },\n // 🔥@workspaces: 项目的工作区配置，用于在本地的根目录下管理多个子项目。\n // 可以自动地在 npm install 时将 workspaces 下面的包，软链到根目录的 node_modules 中，不用手动执行 npm link 操作。\n // 通常子项目都会平铺管理在 packages 目录下，\"packages/*\" 表示将该路径下所有子项目的 node_modules 软链到根目录。\n \"workspaces\": [\n \"packages/*\",\n ],\n}\n```\n\n> 当一个项目同时定义了 main，browser 和 module，像 webpack，rollup 等构建工具会感知这些字段，并会根据环境以及不同的模块规范来进行不同的入口文件查找。\n\n#### `exports` 字段详解\n\n参考 [阮一峰](https://es6.ruanyifeng.com/#docs/module-loader#package-json-%E7%9A%84-exports-%E5%AD%97%E6%AE%B5)\n\n`exports`字段的优先级高于`main`字段。它有多种用法。\n\n1. 子目录别名\n\n`package.json`文件的`exports`字段可以指定脚本或子目录的别名，此时它的前缀的参照拼接路径是包名。\n\n```js\n// ./node_modules/es-module-package/package.json\n{\n \"exports\": {\n \"./submodule\": \"./src/submodule.js\"\n }\n}\n```\n\n上面的代码指定`src/submodule.js`别名为`submodule`，然后就可以从别名加载这个文件。\n\n```js\nimport submodule from 'es-module-package/submodule';\n// 加载 ./node_modules/es-module-package/src/submodule.js\n```\n\n如果没有指定别名，就不能用“模块+脚本名”这种形式加载脚本。\n\n```js\n// 报错\nimport submodule from 'es-module-package/private-module.js';\n\n// 不报错\nimport submodule from './node_modules/es-module-package/private-module.js';\n```\n\n2. main 的别名\n\n`exports`字段的别名如果是`.`，就代表模块的主入口，优先级高于`main`字段，并且可以直接简写成`exports`字段的值。\n\n```js\n{\n \"exports\": {\n \".\": \"./main.js\"\n }\n}\n\n// 等同于\n{\n \"exports\": \"./main.js\"\n}\n```\n\n由于`exports`字段只有支持 ES6 的 Node.js 才认识，所以可以同时添加`main`字段来兼容旧版本的 Node.js。\n\n```\n{\n \"main\": \"./main-legacy.cjs\",\n \"exports\": {\n \".\": \"./main-modern.cjs\"\n }\n}\n```\n\n> 上面代码中，老版本的 Node.js （不支持 ES6 模块）的入口文件是`main-legacy.cjs`，新版本的 Node.js 的入口文件是`main-modern.cjs`。\n\n3. 条件加载\n\n利用`.`这个别名，可以为 ES6 模块和 CommonJS 指定不同的入口。\n\n```json\n{\n \"type\": \"module\",\n \"exports\": {\n \".\": {\n \"require\": \"./main.cjs\",\n \"default\": \"./main.js\"\n }\n }\n}\n```\n\n> 上面代码中，别名`.`的`require`条件指定`require()`命令的入口文件（即 CommonJS 的入口），`default`条件指定其他情况的入口，此处配置了 `type: 'module'`，因此默认命中 ESM 模块规范。\n\n### 脚本配置\n\n```\n{\n // npm run {scripts} / yarn {scripts} 等命令行方式启动预设置的脚本\n \"scripts\": {\n \"build\": \"webpack\"\n },\n // 设置 scripts 里的脚本在运行时的参数\n \"config\": {\n \"port\": \"3001\"\n },\n}\n```\n\n### 依赖配置\n\n项目依赖其他包引用的相关信息。\n```js\n{\n // 项目生产环境(运行时)下需要用到的依赖\n // 使用 npm install xxx 或则 npm install xxx --save 时，会被自动插入到该字段中。\n \"dependencies\": {\n \"react\": \"^18.2.0\",\n \"react-dom\": \"^18.2.0\"\n },\n // 项目开发环境需要用到而运行时不需要的依赖，用于辅助开发\n // 使用 npm install xxx -D 或者 npm install xxx --save-dev 时，会被自动插入到该字段中。\n \"devDependencies\": {\n \"webpack\": \"^5.69.0\"\n },\n // 同伴依赖\n // 一种特殊的依赖，不会被自动安装，通常用于表示与另一个包的依赖与兼容性关系来警示使用者。\n // 比如我们安装 A，A 的正常使用依赖 B@2.x 版本，那么 B@2.x 就应该被列在 A 的 peerDependencies 下，表示“如果你使用我，那么你也需要安装 B，并且至少是 2.x 版本”。\n // 比如 React 组件库 Ant Design，它的 package.json 里 peerDependencies 为\n // 表示如果你使用 Ant Design，那么你的项目也应该安装 react 和 react-dom，并且版本需要大于等于 16.9.0。\n \"peerDependencies\": {\n \"react\": \">=16.9.0\",\n \"react-dom\": \">=16.9.0\"\n },\n // optionalDependencies\n // 可选依赖，顾名思义，表示依赖是可选的，它不会阻塞主功能的使用，安装或者引入失败也无妨。这类依赖如果安装失败，那么 npm 的整个安装过程也是成功的。\n // 比如我们使用 colors 这个包来对 console.log 打印的信息进行着色来增强和区分提示，但它并不是必需的，所以可以将其加入到 optionalDependencies，并且在运行时处理引入失败的逻辑。\n // 使用 npm install xxx -O 或者 npm install xxx --save-optional 时，依赖会被自动插入到该字段中。\n \"optionalDependencies\": {\n \"colors\": \"^1.4.0\"\n },\n // peerDependenciesMeta\n // 同伴依赖也可以使用 peerDependenciesMeta 将其指定为可选的。\n \"peerDependencies\": {\n \"colors\": \"^1.4.0\"\n },\n \"peerDependenciesMeta\": {\n \"colors\": {\n \"optional\": true\n }\n },\n // bundleDependencies\n // 打包依赖。它的值是一个数组，在发布包时，bundleDependencies 里面的依赖都会被一起打包。\n // 比如指定 react 和 react-dom 为打包依赖：\n // 在执行 npm pack 打包生成 tgz 压缩包中，将出现 node_modules 并包含 react 和 react-dom。\n // 需要注意的是，这个字段数组中的值必须是在 dependencies，devDependencies 两个里面声明过的依赖才行。\n // 普通依赖通常从 npm registry 安装，但当你想用一个不在 npm registry 里的包，或者一个被修改过的第三方包时，打包依赖会比普通依赖更好用。\n \"bundleDependencies\": [\n \"react\",\n \"react-dom\"\n ],\n // overrides\n // overrides 可以重写项目依赖的依赖，及其依赖树下某个依赖的版本号，进行包的替换。\n // 比如某个依赖 A，由于一些原因它依赖的包 foo@1.0.0 需要替换，我们可以使用 overrides 修改 foo 的版本号：\n \"overrides\": {\n \"foo\": \"1.1.0-patch\"\n }\n}\n```\n\n### 发布配置\n主要是和项目发布相关的配置。\n\n**private**\n\n如果是私有项目，不希望发布到公共 npm 仓库上，可以将 `private` 设为 true。\n```\n\"private\": true\n```\n\n**publishConfig**\n\n顾名思义，publishConfig 就是 npm 包发布时使用的配置。\n\n比如在安装依赖时指定了 registry 为 taobao 镜像源，但发布时希望在公网发布，就可以指定 publishConfig.registry。\n\n```\n\"publishConfig\": {\n \"registry\": \"https://registry.npmjs.org/\"\n}\n```\n\n\n### 系统配置\n\n和项目关联的系统配置，比如 node 版本或操作系统兼容性之类。这些要求只会起到提示警告的作用，即使用户的环境不符合要求，也不影响安装依赖包。\n\n**engines**\n\n一些项目由于兼容性问题会对 node 或者包管理器有特定的版本号要求，比如：\n\n```\n\"engines\": {\n \"node\": \">=14 <16\",\n \"pnpm\": \">7\"\n}\n```\n要求 node 版本大于等于 14 且小于 16，同时 pnpm 版本号需要大于 7。\n\n\n**os**\n\n在 linux 上能正常运行的项目可能在 windows 上会出现异常，使用 os 字段可以指定项目对操作系统的兼容性要求。\n\n```\n\"os\": [\"darwin\", \"linux\"]\n```\n\n**cpu**\n\n指定项目只能在特定的 CPU 体系上运行。\n\n```\n\"cpu\": [\"x64\", \"ia32\"]\n```\n\n\n\n\n### 第三方配置\n\n一些第三方库或应用在进行某些内部处理时会依赖这些字段，使用它们时需要安装对应的第三方库。\n\n```js\n{\n // 其他工具访问本项目 ts 类型定义时的入口文件\n \"types\": \"./index.d.ts\",\n // npm 上所有的文件都开启 CDN 服务\n \"unpkg\": \"dist/vue.global.js\",\n // 设置项目的浏览器兼容情况, babel 和 autoprefixer 等工具会使用该配置对代码进行转换\n \"browserslist\": [\n \"> 1%\",\n \"last 2 versions\"\n ],\n // 用于 webpack 的 tree-shaking 优化, 指定路径下的文件不参与 tree-shaking 并始终保留。\n \"sideEffects\": [\n \"dist/*\",\n \"es/**/style/*\",\n \"lib/**/style/*\",\n \"*.less\"\n ]\n}\n```\n\n\n### 参考文档\n- https://juejin.cn/post/7145001740696289317\n- https://juejin.cn/post/7161392772665540644\n",{"_54":349,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/311/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/311/timeline",{"_54":352,"_56":57,"_58":353,"_60":354,"_62":355,"_64":356,"_66":357,"_68":358,"_70":359,"_72":360,"_74":361,"_107":362,"_127":128,"_129":26,"_130":-5,"_131":364,"_133":365,"_155":148,"_149":367,"_151":368,"_154":-5,"_158":159,"_160":369,"_165":-5,"_166":370,"_168":371,"_180":373,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/309","https://api.github.com/repos/pro-collection/interview-question/issues/309/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/309/comments","https://api.github.com/repos/pro-collection/interview-question/issues/309/events","https://github.com/pro-collection/interview-question/issues/309",1684987713,"I_kwDOJGDC6c5kbt9B",309,"[webpack] module、chunk 、bundle 的区别【热度: 136】",{"_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},[363],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":240,"_64":241,"_58":242,"_66":243,"_68":244,"_70":245,"_72":246,"_118":247,"_143":366,"_145":249,"_147":148,"_127":128,"_149":250,"_151":251,"_153":-5,"_154":-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},"2023-04-26T13:01:07Z","2023-04-26T13:02:02Z",{"_162":148,"_163":148,"_164":148},"首先上图： \r\n![3 (1)](https://user-images.githubusercontent.com/22188674/234582993-25c40cda-d3ee-4f96-b134-44a950aba11f.png)\r\n\r\n\r\n- 手写下一个一个的文件，它们无论是 `ESM` 还是 `commonJS` 或是 `AMD`，他们都是 `module`\r\n- 当我们写的 `module` 源文件传到 `webpack` 进行打包时，`webpack` 会根据文件引用关系生成 `chunk` 文件，`webpack` 会对这个 `chunk` 文件进行一些操作\r\n- webpack 处理好 chunk 文件后，最后会输出 bundle 文件，这个 bundle 文件包含了经过加载和编译的最终源文件，可以直接在浏览器中运行。\r\n\r\n一般来说一个 chunk 对应一个 bundle，比如上图中的 `utils.js -> chunks 1 -> utils.bundle.js`\r\n\r\n但也有例外，比如说上图中，我就用 `MiniCssExtractPlugin` 从 chunks 0 中抽离出了 `index.bundle.css` 文件\r\n\r\n**总结**： \r\nmodule，chunk 和 bundle 其实就是同一份逻辑代码在不同转换场景下的取了三个名字： \r\n我们直接写出来的是 module，webpack 处理时是 chunk，最后生成浏览器可以直接运行的 bundle。 \r\n",{"_54":372,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/309/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/309/timeline",{"_54":375,"_56":57,"_58":376,"_60":377,"_62":378,"_64":379,"_66":380,"_68":381,"_70":382,"_72":383,"_74":384,"_107":385,"_127":128,"_129":26,"_130":-5,"_131":387,"_133":388,"_155":148,"_149":390,"_151":391,"_154":-5,"_158":159,"_160":392,"_165":-5,"_166":393,"_168":394,"_180":396,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/289","https://api.github.com/repos/pro-collection/interview-question/issues/289/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/289/comments","https://api.github.com/repos/pro-collection/interview-question/issues/289/events","https://github.com/pro-collection/interview-question/issues/289",1669999997,"I_kwDOJGDC6c5jii19",289,"[webpack] 分包的方式有哪些？",{"_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},[386],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":389,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-04-16T14:37:43Z","2023-04-16T14:37:44Z",{"_162":148,"_163":148,"_164":148},"### 在 Webpack 中，可以通过以下方式进行分包\n\n1. 通过 `entry` 属性指定入口文件，在打包时，Webpack 会按照入口文件生成一个 chunk，每个 chunk 包含了一组代码块，最终生成一个或多个 bundle。\n\n2. 通过 `SplitChunksPlugin` 插件对公共依赖进行分割。该插件会把公共依赖提取出来，形成一个或多个独立的 chunk，以便在多个 bundle 中共享。\n\n3. 使用动态导入（Dynamic Import）技术进行按需加载。在代码中使用 `import()` 或 `require.ensure()`，Webpack 会将这些代码块按照配置的策略进行分割，生成一个或多个独立的 chunk。\n\n4. 使用 `DllPlugin` 插件将一些不经常变化的代码提取出来，形成一个动态链接库（DLL）。在打包时，可以直接引用这个 DLL，而不必重复打包。\n\n5. 通过 `externals` 属性将一些模块声明为外部依赖。在打包时，Webpack 会跳过这些模块的打包过程，而是在运行时从外部环境中加载。\n\n### SplitChunksPlugin 是怎么对公共依赖进行分割的 ?\n\nWebpack的SplitChunksPlugin插件是用来对公共依赖进行分割的，其原理是将公共模块提取出来，形成一个或多个共享块，并在需要时动态加载。这个插件会分析模块之间的依赖关系，将具有相同引用模块的代码块进行提取，以便于实现缓存和更快的加载。\n\nSplitChunksPlugin的默认配置包括以下三个块：\n\n1. 通过异步加载（异步块）生成的代码块\n2. 与初始块（即入口点）共享的代码块\n3. 在两个或更多块之间共享的代码块\n\n其中，第二个块是最常见的，它包括从多个入口点引用的公共模块。我们可以通过以下示例来说明：\n\n```javascript\n// webpack.config.js\nmodule.exports = {\n entry: {\n main: './src/main.js',\n other: './src/other.js'\n },\n optimization: {\n splitChunks: {\n cacheGroups: {\n commons: {\n test: /[\\\\/]node_modules[\\\\/]/,\n name: 'vendors',\n chunks: 'all'\n }\n }\n }\n }\n};\n```\n\n在上面的配置中，我们定义了两个入口点`main`和`other`，并将`SplitChunksPlugin`配置为将从`node_modules`目录中引用的代码提取到名为`vendors`的代码块中。这个代码块将被引用到我们的入口点中，以便于减少加载时间和提高性能。\n\n当我们打包时，Webpack将分析这两个入口点，并发现它们都引用了`node_modules`目录下的依赖，于是将这些依赖提取到`vendors`代码块中。我们可以在`main.js`和`other.js`中看到这样的代码：\n\n```javascript\nimport 'lodash'; // 公共模块被引用\n```\n\n通过这种方式，Webpack能够将公共代码提取到单独的代码块中，以便于更高效地加载和缓存。\n\n\n### webpack DllPlugin 是如何提取依赖的？\nWebpack DllPlugin 是用于将某些库（例如第三方库）提前编译和打包，以便在开发和生产构建过程中减少依赖项的分析时间，提高打包速度的插件。\n\n具体来说，DllPlugin 分为两个步骤：第一步是生成一个包含库的映射文件（manifest.json），第二步是在开发或生产构建中使用该映射文件来引入预编译的库。\n\nDllPlugin 的基本原理是将库单独编译成一个或多个 dll 文件（动态链接库），同时生成一个 manifest.json 文件记录这些库文件的名称、路径等信息。在开发或生产构建过程中，通过引用 manifest.json 文件，将已经预编译好的库文件引入到项目中。这样可以避免在每次打包时都去分析和打包第三方库，提高构建速度。\n\n下面是一个简单的例子：\n\n在 webpack.config.dll.js 中定义打包的库：\n\n```lua\nluaCopy codeconst path = require('path');\nconst webpack = require('webpack');\n\nmodule.exports = {\n mode: 'production',\n entry: {\n vendor: ['react', 'react-dom', 'lodash']\n },\n output: {\n path: path.join(__dirname, 'dist'),\n filename: '[name].dll.js',\n library: '[name]'\n },\n plugins: [\n new webpack.DllPlugin({\n name: '[name]',\n path: path.join(__dirname, 'dist', '[name].manifest.json')\n })\n ]\n};\n```\n\n然后运行 `webpack --config webpack.config.dll.js`，会生成 `vendor.dll.js` 和 `vendor.manifest.json` 文件。\n\n在开发或生产环境中，通过引入生成的 manifest.json 文件，将预编译好的库文件引入项目中：\n\n```lua\nluaCopy codeconst path = require('path');\nconst webpack = require('webpack');\n\nmodule.exports = {\n mode: 'production',\n entry: {\n app: './src/index.js'\n },\n output: {\n path: path.join(__dirname, 'dist'),\n filename: '[name].js'\n },\n plugins: [\n new webpack.DllReferencePlugin({\n manifest: require('./dist/vendor.manifest.json')\n })\n ]\n};\n```\n\n这样，在打包过程中，webpack 会自动将 `vendor.dll.js` 中包含的第三方库从项目中分离出来，而不需要重复打包和分析这些库。\n",{"_54":395,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/289/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/289/timeline",{"_54":398,"_56":57,"_58":399,"_60":400,"_62":401,"_64":402,"_66":403,"_68":404,"_70":405,"_72":406,"_74":407,"_107":408,"_127":128,"_129":26,"_130":-5,"_131":411,"_133":412,"_155":148,"_149":414,"_151":414,"_154":-5,"_158":159,"_160":415,"_165":-5,"_166":416,"_168":417,"_180":419,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/288","https://api.github.com/repos/pro-collection/interview-question/issues/288/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/288/comments","https://api.github.com/repos/pro-collection/interview-question/issues/288/events","https://github.com/pro-collection/interview-question/issues/288",1669997011,"I_kwDOJGDC6c5jiiHT",288,"[webpack] externals 作用是啥？",{"_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},[409,410],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":200,"_68":201,"_54":202,"_113":203,"_115":125,"_117":26,"_118":126},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":413,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-04-16T14:30:00Z",{"_162":148,"_163":148,"_164":148},"`webpack` 中的 `externals` 配置项用于指定在打包时需要排除掉的模块，这些模块会被视为外部依赖，即不会被打包进最终的输出文件中，而是通过其他方式引入。\n\n使用 `externals` 配置项可以使得打包后的代码文件更小，同时也可以在运行时从外部获取依赖，例如通过 CDN、全局变量或者通过 `require` 的方式等。\n\n举个例子，假设我们需要在项目中引入 `jquery` 库，但我们并不想在打包的过程中将其打包进最终的输出文件中，而是从外部引入。我们可以通过以下的配置来实现：\n\n```js\nmodule.exports = {\n // ...\n externals: {\n jquery: 'jQuery'\n }\n};\n```\n\n这里的 `externals` 配置项告诉 `webpack` 在打包时忽略 `jquery` 模块的引用，而在代码运行时，我们需要手动将 `jquery` 通过 `script` 标签引入，并将其暴露在全局变量 `jQuery` 下，例如：\n\n```html\n\n\n```\n\n这样在代码中引入 `jquery` 模块时，`webpack` 就会将其作为外部依赖进行处理，而不是将其打包进输出文件中。\n\n需要注意的是，使用 `externals` 配置项需要谨慎，因为如果在运行时无法正确获取到指定的外部依赖，就会导致代码运行出错。",{"_54":418,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/288/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/288/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,"_127":128,"_129":26,"_130":-5,"_131":434,"_133":435,"_155":148,"_149":437,"_151":438,"_154":-5,"_158":159,"_160":439,"_165":-5,"_166":440,"_168":441,"_180":443,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/287","https://api.github.com/repos/pro-collection/interview-question/issues/287/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/287/comments","https://api.github.com/repos/pro-collection/interview-question/issues/287/events","https://github.com/pro-collection/interview-question/issues/287",1669996048,"I_kwDOJGDC6c5jih4Q",287,"[webpack] 异步加载原理是啥",{"_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,433],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":200,"_68":201,"_54":202,"_113":203,"_115":125,"_117":26,"_118":126},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":436,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-04-16T14:27:01Z","2023-04-16T14:27:02Z",{"_162":148,"_163":148,"_164":148},"### Webpack 异步加载模块的方式主要有以下几种\n\n1. 使用动态 import: 使用 ES6 的 `import()` 语法，动态加载模块。\n\n```javascript\nimport('./path/to/module')\n .then(module => {\n // do something with module\n })\n .catch(error => {\n // handle error\n });\n```\n\n2. 使用 require.ensure: 异步加载模块并将其放置到指定的 chunk 中。\n\n```javascript\nrequire.ensure(['./path/to/module'], function(require) {\n const module = require('./path/to/module');\n // do something with module\n});\n```\n\n3. 使用 bundle-loader: 将模块放置到一个单独的文件中，按需加载。\n\n```javascript\nconst load = require('bundle-loader!./path/to/module');\nload(function(module) {\n // do something with module\n});\n```\n\n4. 使用webpack的require.ensure API\n\n```javascript\nrequire.ensure([], function(require) {\n // require dependencies\n var foo = require(\"./foo\");\n // ...\n});\n```\n\n5. 使用webpack的import动态导入\n\n```javascript\nimport(\"./dynamic-module.js\").then(module => {\n // do something with module\n});\n```\n\n这些方式都可以在 Webpack 中使用，具体使用哪种方式，取决于具体的场景和需求。\n\n### 动态加载的原理\n在 Webpack 中，异步加载组件的原理是利用动态导入（Dynamic import）特性。使用动态导入可以将模块的加载从编译时刻延迟到运行时刻。\n\n具体来说，当 Webpack 打包代码时，遇到动态导入语句时不会将其打包进入主文件，而是将其单独打包为一个新的文件。在运行时，当代码需要加载该组件时，会通过网络请求动态加载该文件。\n\n这样做的好处是可以减小主文件的体积，从而加快页面的加载速度，并且也可以提高代码的灵活性和可维护性。同时，Webpack 还可以对动态加载的文件进行代码分割和按需加载，进一步优化页面的性能。\n\n在使用动态导入时，需要注意一些细节。例如，在支持动态导入的浏览器中，需要使用 `import()` 函数进行动态导入；而在不支持动态导入的浏览器中，需要使用 Webpack 提供的 `require.ensure` 或 `require.include` 等方法进行模块的异步加载。同时，还需要注意动态导入的兼容性和性能问题。\n",{"_54":442,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/287/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/287/timeline",{"_54":445,"_56":57,"_58":446,"_60":447,"_62":448,"_64":449,"_66":450,"_68":451,"_70":452,"_72":453,"_74":454,"_107":455,"_127":128,"_129":26,"_130":-5,"_131":457,"_133":458,"_155":185,"_149":460,"_151":461,"_154":-5,"_158":159,"_160":462,"_165":-5,"_166":463,"_168":464,"_180":466,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/284","https://api.github.com/repos/pro-collection/interview-question/issues/284/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/284/comments","https://api.github.com/repos/pro-collection/interview-question/issues/284/events","https://github.com/pro-collection/interview-question/issues/284",1664723460,"I_kwDOJGDC6c5jOaoE",284,"[webpack] 核心库 - tapable 的设计思路与实现原理是什么？",{"_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},[456],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":206,"_64":207,"_58":208,"_66":209,"_68":210,"_70":211,"_72":212,"_118":213,"_143":459,"_145":215,"_147":148,"_127":128,"_149":216,"_151":217,"_153":-5,"_154":-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},"2023-04-12T14:51:55Z","2023-04-12T14:56:38Z",{"_162":148,"_163":148,"_164":148},"### Webpack Tapable 的设计思路 \n\nWebpack Tapable 的设计思路主要基于观察者模式（Observer Pattern）和发布-订阅模式（Publish-Subscribe Pattern），用于解耦各个插件之间的依赖关系，让插件能够独立作用于特定的钩子（Hook），从而实现可扩展性和灵活性。\n\n具体来说，Tapable 采用了钩子（Hook）的概念，每个钩子对应一组事件，Webpack 在不同的时刻触发这些钩子，插件可以注册自己的事件处理函数到对应的钩子上，以实现各种功能。\n\n为了避免插件之间的耦合，Tapable 将事件处理函数按照钩子类型分为同步钩子（Sync Hook）、异步钩子（Async Hook）、单向异步钩子（Async Parallel Hook）和多向异步钩子（Async Series Hook）四种类型。这样，不同类型的钩子对应着不同的事件处理顺序和调用方式，插件在注册自己的事件处理函数时，可以选择不同的钩子类型来适应不同的应用场景。\n\n除此之外，Tapable 还提供了一些辅助方法和工具函数，用于方便地创建和管理钩子、向钩子注册事件处理函数、调用钩子的事件处理函数等。这些工具函数的设计思路也遵循了解耦、简单易用的原则，为插件开发提供了很大的便利性。\n\n### Tapable 的使用\n\nWebpack Tapable 的使用分为三个步骤：\n\n1. 定义一个新的 Tapable 实例：在 Webpack 插件中定义一个新的 Tapable 实例，并定义需要监听的事件。\n\n```javascript\nconst { SyncHook } = require('tapable');\n\nclass MyPlugin {\n constructor() {\n this.hooks = {\n beforeRun: new SyncHook(['compiler']),\n done: new SyncHook(['stats'])\n };\n }\n\n apply(compiler) {\n this.hooks.beforeRun.tap('MyPlugin', compiler => {\n console.log('Webpack is starting to run...');\n });\n\n this.hooks.done.tap('MyPlugin', stats => {\n console.log('Webpack has finished running.');\n });\n }\n}\n```\n\n2. 触发事件：在 Webpack 的编译过程中，调用 Tapable 实例的触发方法，触发事件。\n\n```javascript\ncompiler.hooks.beforeRun.call(compiler);\n// Webpack is starting to run...\n\ncompiler.run((err, stats) => {\n if (err) {\n console.error(err);\n return;\n }\n\n console.log(stats);\n compiler.hooks.done.call(stats);\n // Webpack has finished running.\n});\n```\n\n3. 注册插件：在 Webpack 的配置文件中，将插件实例注册到 Webpack 中。\n\n```javascript\nconst MyPlugin = require('./my-plugin');\n\nmodule.exports = {\n plugins: [new MyPlugin()]\n};\n```\n\n以上是使用 Tapable 的基本流程，通过 Tapable 可以监听到编译过程中的各个事件，并对编译过程进行修改，从而实现各种插件。以下是一些常见的 Tapable 类型和用法：\n\n* SyncHook：同步 Hook，按照注册的顺序同步执行所有回调函数。\n\n```javascript\nconst { SyncHook } = require('tapable');\n\nconst hook = new SyncHook(['arg1', 'arg2']);\n\nhook.tap('MyPlugin', (arg1, arg2) => {\n console.log(`Hook is triggered with arguments: ${arg1}, ${arg2}`);\n});\n\nhook.tap('MyPlugin', (arg1, arg2) => {\n console.log('Second callback is called');\n});\n\nhook.call('Hello', 'world');\n// Hook is triggered with arguments: Hello, world\n// Second callback is called\n```\n\n* AsyncParallelHook：异步 Hook，按照注册的顺序异步执行所有回调函数，不关心回调函数的返回值。\n\n```javascript\nconst { AsyncParallelHook } = require('tapable');\n\nconst hook = new AsyncParallelHook(['arg1', 'arg2']);\n\nhook.tap('MyPlugin', (arg1, arg2, callback) => {\n setTimeout(() => {\n console.log(`Hook is triggered with arguments: ${arg1}, ${arg2}`);\n callback();\n }, 1000);\n});\n\nhook.tap('MyPlugin', (arg1, arg2, callback) => {\n setTimeout(() => {\n console.log('Second callback is called');\n callback();\n }, 500)\n})\n```\n\n\n### Tapable 是如何实现的？代码简单实现一下？\n\nWebpack Tapable 是基于发布-订阅模式的一个插件系统，它提供了一组钩子函数，让插件可以在相应的时机执行自己的逻辑。\n\n下面是一个简单的自定义 Tapable 的实现：\n\n```javascript\nclass Tapable {\n constructor() {\n this.hooks = {};\n }\n\n // 注册事件监听函数\n tap(name, callback) {\n if (!this.hooks[name]) {\n this.hooks[name] = [];\n }\n this.hooks[name].push(callback);\n }\n\n // 触发事件\n call(name, ...args) {\n const callbacks = this.hooks[name];\n if (callbacks && callbacks.length) {\n callbacks.forEach((callback) => callback(...args));\n }\n }\n}\n```\n\n在这个例子中，我们定义了一个 `Tapable` 类，它有一个 `hooks` 对象属性，用于存储各个事件对应的监听函数。然后我们定义了 `tap` 方法，用于注册事件监听函数，以及 `call` 方法，用于触发事件。\n\n下面是一个使用自定义 Tapable 的例子：\n\n```javascript\nconst tapable = new Tapable();\n\ntapable.tap('event1', (arg1, arg2) => {\n console.log('event1 is triggered with arguments:', arg1, arg2);\n});\n\ntapable.tap('event2', (arg1, arg2) => {\n console.log('event2 is triggered with arguments:', arg1, arg2);\n});\n\ntapable.call('event1', 'hello', 'world');\ntapable.call('event2', 'foo', 'bar');\n```\n\n在这个例子中，我们定义了两个事件 `event1` 和 `event2`，并为它们注册了监听函数。当我们调用 `call` 方法触发事件时，注册的监听函数就会依次执行。\n\n这个自定义 Tapable 的实现虽然简单，但它体现了 Tapable 的设计思路和核心功能。在实际使用中，Webpack 的 Tapable 提供了更多的功能和钩子，可以满足不同场景的需求。\n",{"_54":465,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/284/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/284/timeline",{"_54":468,"_56":57,"_58":469,"_60":470,"_62":471,"_64":472,"_66":473,"_68":474,"_70":475,"_72":476,"_74":477,"_107":478,"_127":128,"_129":26,"_130":-5,"_131":480,"_133":481,"_155":185,"_149":483,"_151":484,"_154":-5,"_158":159,"_160":485,"_165":-5,"_166":486,"_168":487,"_180":489,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/283","https://api.github.com/repos/pro-collection/interview-question/issues/283/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/283/comments","https://api.github.com/repos/pro-collection/interview-question/issues/283/events","https://github.com/pro-collection/interview-question/issues/283",1664677383,"I_kwDOJGDC6c5jOPYH",283,"[webpack] 构建流程是怎么样的？",{"_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},[479],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":482,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-04-12T14:25:39Z","2023-05-31T14:45:00Z",{"_162":148,"_163":148,"_164":148},"`webpack` 的运行流程是一个串行的过程，它的工作流程就是将各个插件串联起来\n\n在运行过程中会广播事件，插件只需要监听它所关心的事件，就能加入到这条`webpack`机制中，去改变`webpack`的运作，使得整个系统扩展性良好\n\n从启动到结束会依次执行以下三大步骤：\n\n* 初始化流程：从配置文件和 `Shell` 语句中读取与合并参数，并初始化需要使用的插件和配置插件等执行环境所需要的参数\n* 编译构建流程：从 Entry 发出，针对每个 Module 串行调用对应的 Loader 去翻译文件内容，再找到该 Module 依赖的 Module，递归地进行编译处理\n* 输出流程：对编译后的 Module 组合成 Chunk，把 Chunk 转换成文件，输出到文件系统\n\n\n### 初始化流程\n\n从配置文件和 `Shell` 语句中读取与合并参数，得出最终的参数\n\n配置文件默认下为`webpack.config.js`，也或者通过命令的形式指定配置文件，主要作用是用于激活`webpack`的加载项和插件\n\n`webpack` 将 `webpack.config.js` 中的各个配置项拷贝到 `options` 对象中，并加载用户配置的 `plugins` \n完成上述步骤之后，则开始初始化`Compiler`编译对象，该对象掌控者`webpack`声明周期，不执行具体的任务，只是进行一些调度工作\n\n```js\nclass Compiler extends Tapable {\n constructor(context) {\n super();\n this.hooks = {\n beforeCompile: new AsyncSeriesHook([\"params\"]),\n compile: new SyncHook([\"params\"]),\n afterCompile: new AsyncSeriesHook([\"compilation\"]),\n make: new AsyncParallelHook([\"compilation\"]),\n entryOption: new SyncBailHook([\"context\", \"entry\"])\n // 定义了很多不同类型的钩子\n };\n // ...\n }\n}\n\nfunction webpack(options) {\n var compiler = new Compiler();\n ...// 检查options,若watch字段为true,则开启watch线程\n return compiler;\n}\n...\n\n```\n\n`Compiler` 对象继承自 `Tapable`，初始化时定义了很多钩子函数\n\n### 编译构建流程\n\n根据配置中的 `entry` 找出所有的入口文件\n\n```js\nmodule.exports = {\n entry: './src/file.js'\n}\n\n```\n\n初始化完成后会调用`Compiler`的`run`来真正启动`webpack`编译构建流程，主要流程如下：\n\n* `compile` 开始编译\n* `make` 从入口点分析模块及其依赖的模块，创建这些模块对象\n* `build-module` 构建模块\n* `seal` 封装构建结果\n* `emit` 把各个chunk输出到结果文件\n\n#### compile 编译\n\n执行了`run`方法后，首先会触发`compile`，主要是构建一个`Compilation`对象\n\n该对象是编译阶段的主要执行者，主要会依次下述流程：执行模块创建、依赖收集、分块、打包等主要任务的对象\n\n#### make 编译模块\n\n当完成了上述的`compilation`对象后，就开始从`Entry`入口文件开始读取，主要执行`_addModuleChain()`函数，如下：\n\n```js\n_addModuleChain(context, dependency, onModule, callback) {\n ...\n // 根据依赖查找对应的工厂函数\n const Dep = /** @type {DepConstructor} */ (dependency.constructor);\n const moduleFactory = this.dependencyFactories.get(Dep);\n\n // 调用工厂函数NormalModuleFactory的create来生成一个空的NormalModule对象\n moduleFactory.create({\n dependencies: [dependency]\n ...\n }, (err, module) => {\n ...\n const afterBuild = () => {\n this.processModuleDependencies(module, err => {\n if (err) return callback(err);\n callback(null, module);\n });\n };\n\n this.buildModule(module, false, null, null, err => {\n ...\n afterBuild();\n })\n })\n}\n\n```\n\n过程如下：\n\n`_addModuleChain`中接收参数`dependency`传入的入口依赖，使用对应的工厂函数`NormalModuleFactory.create`方法生成一个空的`module`对象\n\n回调中会把此`module`存入`compilation.modules`对象和`dependencies.module`对象中，由于是入口文件，也会存入`compilation.entries`中\n\n随后执行`buildModule`进入真正的构建模块`module`内容的过程\n\n#### build module 完成模块编译\n\n这里主要调用配置的`loaders`，将我们的模块转成标准的`JS`模块\n\n在用`Loader` 对一个模块转换完后，使用 `acorn` 解析转换后的内容，输出对应的抽象语法树（`AST`），以方便 `Webpack`后面对代码的分析\n\n从配置的入口模块开始，分析其 `AST`，当遇到`require`等导入其它模块语句时，便将其加入到依赖的模块列表，同时对新找出的依赖模块递归分析，最终搞清所有模块的依赖关系\n\n### 输出流程\n\n#### seal 输出资源\n\n`seal`方法主要是要生成`chunks`，对`chunks`进行一系列的优化操作，并生成要输出的代码\n\n`webpack` 中的 `chunk` ，可以理解为配置在 `entry` 中的模块，或者是动态引入的模块\n\n根据入口和模块之间的依赖关系，组装成一个个包含多个模块的 `Chunk`，再把每个 `Chunk` 转换成一个单独的文件加入到输出列表\n\n#### emit 输出完成\n\n在确定好输出内容后，根据配置确定输出的路径和文件名\n\n```js\noutput: {\n path: path.resolve(__dirname, 'build'),\n filename: '[name].js'\n}\n\n```\n\n在 `Compiler` 开始生成文件前，钩子 `emit` 会被执行，这是我们修改最终文件的最后一个机会\n\n从而`webpack`整个打包过程则结束了\n\n### 小结\n\n![](https://foruda.gitee.com/images/1681308948652266689/0b4f6e27_7819612.png)\n",{"_54":488,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/283/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/283/timeline",{"_54":491,"_56":57,"_58":492,"_60":493,"_62":494,"_64":495,"_66":496,"_68":497,"_70":498,"_72":499,"_74":500,"_107":501,"_127":128,"_129":26,"_130":-5,"_131":504,"_133":505,"_155":148,"_149":507,"_151":508,"_154":-5,"_158":159,"_160":509,"_165":-5,"_166":510,"_168":511,"_180":513,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/270","https://api.github.com/repos/pro-collection/interview-question/issues/270/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/270/comments","https://api.github.com/repos/pro-collection/interview-question/issues/270/events","https://github.com/pro-collection/interview-question/issues/270",1659768390,"I_kwDOJGDC6c5i7g5G",270,"小程序的大概原理?",{"_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},[502,503],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":200,"_68":201,"_54":202,"_113":203,"_115":125,"_117":26,"_118":126},[],{"_54":206,"_64":207,"_58":208,"_66":209,"_68":210,"_70":211,"_72":212,"_118":213,"_143":506,"_145":215,"_147":148,"_127":128,"_149":216,"_151":217,"_153":-5,"_154":-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},"2023-04-09T06:30:09Z","2023-04-09T06:30:10Z",{"_162":148,"_163":148,"_164":148},"具体流程可以看下面这个图：\n![](https://foruda.gitee.com/images/1681021603016376642/cc6178f0_7819612.png)\n\n要了解小程序架构原理，要从以下几个方面入手探索\n- 宿主环境\n- 执行环境\n- 小程序整体架构\n- 运行机制\n- 更新机制\n- 数据通信机制\n- 登录机制\n- 性能方向问题\n- JSCore\n\n具体内容可以参考文档:\n- https://juejin.cn/post/6976805521407868958\n",{"_54":512,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/270/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/270/timeline",{"_54":515,"_56":57,"_58":516,"_60":517,"_62":518,"_64":519,"_66":520,"_68":521,"_70":522,"_72":523,"_74":524,"_107":525,"_127":128,"_129":26,"_130":-5,"_131":527,"_133":528,"_155":245,"_149":530,"_151":531,"_154":-5,"_158":159,"_160":532,"_165":-5,"_166":533,"_168":534,"_180":536,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/267","https://api.github.com/repos/pro-collection/interview-question/issues/267/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/267/comments","https://api.github.com/repos/pro-collection/interview-question/issues/267/events","https://github.com/pro-collection/interview-question/issues/267",1659746104,"I_kwDOJGDC6c5i7bc4",267,"[Webpack] webpack热更新原理是什么？",{"_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},[526],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":206,"_64":207,"_58":208,"_66":209,"_68":210,"_70":211,"_72":212,"_118":213,"_143":529,"_145":215,"_147":148,"_127":128,"_149":216,"_151":217,"_153":-5,"_154":-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},"2023-04-09T04:38:38Z","2024-05-26T06:11:01Z",{"_162":148,"_163":148,"_164":148},"> `Hot Module Replacement`，简称`HMR`，无需完全刷新整个页面的同时，更新模块。`HMR`的好处，在日常开发工作中体会颇深：**节省宝贵的开发时间、提升开发体验**。\r\n\r\n刷新我们一般分为两种：\r\n\r\n* 一种是页面刷新，不保留页面状态，就是简单粗暴，直接`window.location.reload()`。\r\n* 另一种是基于`WDS (Webpack-dev-server)`的模块热替换，只需要局部刷新页面上发生变化的模块，同时可以保留当前的页面状态，比如复选框的选中状态、输入框的输入等。\r\n\r\n`HMR`作为一个`Webpack`内置的功能，可以通过`HotModuleReplacementPlugin`或`--hot`开启。那么，`HMR`到底是怎么实现热更新的呢？下面让我们来了解一下吧！\r\n\r\n\r\n### 1. webpack-dev-server启动本地服务\r\n\r\n我们根据`webpack-dev-server`的`package.json`中的`bin`命令，可以找到命令的入口文件`bin/webpack-dev-server.js`。\r\n\r\n```pgsql\r\n// node_modules/webpack-dev-server/bin/webpack-dev-server.js\r\n\r\n// 生成webpack编译主引擎 compiler\r\nlet compiler = webpack(config);\r\n\r\n// 启动本地服务\r\nlet server = new Server(compiler, options, log);\r\nserver.listen(options.port, options.host, (err) => {\r\n if (err) {throw err};\r\n});\r\n```\r\n\r\n本地服务代码：\r\n\r\n```javascript\r\n// node_modules/webpack-dev-server/lib/Server.js\r\nclass Server {\r\n constructor() {\r\n this.setupApp();\r\n this.createServer();\r\n }\r\n\r\n setupApp() {\r\n // 依赖了express\r\n \tthis.app = new express();\r\n }\r\n\r\n createServer() {\r\n this.listeningApp = http.createServer(this.app);\r\n }\r\n listen(port, hostname, fn) {\r\n return this.listeningApp.listen(port, hostname, (err) => {\r\n // 启动express服务后，启动websocket服务\r\n this.createSocketServer();\r\n }\r\n }\r\n}\r\n```\r\n\r\n这一小节代码主要做了三件事：\r\n\r\n* 启动`webpack`，生成`compiler`实例。`compiler`上有很多方法，比如可以启动 `webpack` 所有**编译**工作，以及**监听**本地文件的变化。\r\n* 使用`express`框架启动本地`server`，让浏览器可以请求本地的**静态资源**。\r\n* 本地`server`启动之后，再去启动`websocket`服务，如果不了解`websocket`，建议简单了解一下[websocket速成](https://link.juejin.cn?target=https%3A%2F%2Fwww.ruanyifeng.com%2Fblog%2F2017%2F05%2Fwebsocket.html \"https://www.ruanyifeng.com/blog/2017/05/websocket.html\")。通过`websocket`，可以建立本地服务和浏览器的双向通信。这样就可以实现当本地文件发生变化，立马告知浏览器可以热更新代码啦！\r\n\r\n上述代码主要干了三件事，但是源码在启动服务前又做了很多事，接下来便看看`webpack-dev-server/lib/Server.js`还做了哪些事？\r\n\r\n### 2. 修改webpack.config.js的entry配置\r\n\r\n启动本地服务前，调用了`updateCompiler(this.compiler)`方法。这个方法中有 2 段关键性代码。一个是获取`websocket`客户端代码路径，另一个是根据配置获取`webpack`热更新代码路径。\r\n\r\n```javascript\r\n// 获取websocket客户端代码\r\nconst clientEntry = `${require.resolve(\r\n '../../client/'\r\n)}?${domain}${sockHost}${sockPath}${sockPort}`;\r\n\r\n// 根据配置获取热更新代码\r\nlet hotEntry;\r\nif (options.hotOnly) {\r\n hotEntry = require.resolve('webpack/hot/only-dev-server');\r\n} else if (options.hot) {\r\n hotEntry = require.resolve('webpack/hot/dev-server');\r\n}\r\n```\r\n\r\n修改后的`webpack`入口配置如下：\r\n\r\n```awk\r\n// 修改后的entry入口\r\n{ entry:\r\n { index:\r\n [\r\n // 上面获取的clientEntry\r\n 'xxx/node_modules/webpack-dev-server/client/index.js?http://localhost:8080',\r\n // 上面获取的hotEntry\r\n 'xxx/node_modules/webpack/hot/dev-server.js',\r\n // 开发配置的入口\r\n './src/index.js'\r\n \t],\r\n },\r\n} \r\n```\r\n\r\n为什么要新增了 2 个文件？在入口默默增加了 2 个文件，那就意味会一同打包到`bundle`文件中去，也就是线上运行时。\r\n\r\n**（1）webpack-dev-server/client/index.js**\r\n\r\n首先这个文件用于`websocket`的，因为`websoket`是双向通信，如果不了解`websocket`，建议简单了解一下[websocket速成](https://link.juejin.cn?target=https%3A%2F%2Fwww.ruanyifeng.com%2Fblog%2F2017%2F05%2Fwebsocket.html \"https://www.ruanyifeng.com/blog/2017/05/websocket.html\")。我们在第 1 步 `webpack-dev-server`初始化的过程中，启动的是本地服务端的`websocket`。那客户端也就是我们的浏览器，浏览器还没有和服务端通信的代码呢？总不能让开发者去写吧hhhhhh。因此我们需要把`websocket`客户端通信代码偷偷塞到我们的代码中。客户端具体的代码后面会在合适的时机细讲哦。\r\n\r\n**（2）webpack/hot/dev-server.js**\r\n\r\n这个文件主要是用于检查更新逻辑的，这里大家知道就好，代码后面会在合适的时机（**第5步**）细讲。\r\n\r\n### 3. 监听webpack编译结束\r\n\r\n修改好入口配置后，又调用了`setupHooks`方法。这个方法是用来注册监听事件的，监听每次`webpack`编译完成。\r\n\r\n```javascript\r\n// node_modules/webpack-dev-server/lib/Server.js\r\n// 绑定监听事件\r\nsetupHooks() {\r\n const {done} = compiler.hooks;\r\n // 监听webpack的done钩子，tapable提供的监听方法\r\n done.tap('webpack-dev-server', (stats) => {\r\n this._sendStats(this.sockets, this.getStats(stats));\r\n this._stats = stats;\r\n });\r\n};\r\n```\r\n\r\n当监听到一次`webpack`编译结束，就会调用`_sendStats`方法通过`websocket`给浏览器发送通知，`ok`和`hash`事件，这样浏览器就可以拿到最新的`hash`值了，做检查更新逻辑。\r\n\r\n```reasonml\r\n// 通过websoket给客户端发消息\r\n_sendStats() {\r\n this.sockWrite(sockets, 'hash', stats.hash);\r\n this.sockWrite(sockets, 'ok');\r\n}\r\n```\r\n\r\n### 4. webpack监听文件变化\r\n\r\n每次修改代码，就会触发编译。说明我们还需要监听本地代码的变化，主要是通过`setupDevMiddleware`方法实现的。\r\n\r\n这个方法主要执行了`webpack-dev-middleware`库。很多人分不清`webpack-dev-middleware`和`webpack-dev-server`的区别。其实就是因为`webpack-dev-server`只负责启动服务和前置准备工作，所有文件相关的操作都抽离到`webpack-dev-middleware`库了，主要是本地文件的**编译**和**输出**以及**监听**，无非就是职责的划分更清晰了。\r\n\r\n那我们来看下`webpack-dev-middleware`源码里做了什么事:\r\n\r\n```awk\r\n// node_modules/webpack-dev-middleware/index.js\r\ncompiler.watch(options.watchOptions, (err) => {\r\n if (err) { /*错误处理*/ }\r\n});\r\n\r\n// 通过“memory-fs”库将打包后的文件写入内存\r\nsetFs(context, compiler); \r\n```\r\n\r\n（1）调用了`compiler.watch`方法，在第 1 步中也提到过，`compiler`的强大。这个方法主要就做了 2 件事：\r\n\r\n* 首先对本地文件代码进行编译打包，也就是`webpack`的一系列编译流程。\r\n* 其次编译结束后，开启对本地文件的监听，当文件发生变化，重新编译，编译完成之后继续监听。\r\n\r\n为什么代码的改动保存会自动编译，重新打包？这一系列的重新检测编译就归功于`compiler.watch`这个方法了。监听本地文件的变化主要是通过**文件的生成时间**是否有变化，这里就不细讲了。\r\n\r\n（2）执行`setFs`方法，这个方法主要目的就是将编译后的文件打包到内存。这就是为什么在开发的过程中，你会发现`dist`目录没有打包后的代码，因为都在内存中。原因就在于访问内存中的代码比访问文件系统中的文件更快，而且也减少了代码写入文件的开销，这一切都归功于`memory-fs`。\r\n\r\n### 5. 浏览器接收到热更新的通知\r\n\r\n我们已经可以监听到文件的变化了，当文件发生变化，就触发重新编译。同时还监听了每次编译结束的事件。当监听到一次`webpack`编译结束，`_sendStats`方法就通过`websoket`给浏览器发送通知，检查下是否需要热更新。下面重点讲的就是`_sendStats`方法中的`ok`和`hash`事件都做了什么。\r\n\r\n那浏览器是如何接收到`websocket`的消息呢？回忆下第 2 步骤增加的入口文件，也就是`websocket`客户端代码。\r\n\r\n```\r\n'xxx/node_modules/webpack-dev-server/client/index.js?http://localhost:8080'\r\n```\r\n\r\n这个文件的代码会被打包到`bundle.js`中，运行在浏览器中。来看下这个文件的核心代码吧。\r\n\r\n```js\r\n// webpack-dev-server/client/index.js\r\nvar socket = require('./socket');\r\nvar onSocketMessage = {\r\n hash: function hash(_hash) {\r\n // 更新currentHash值\r\n status.currentHash = _hash;\r\n },\r\n ok: function ok() {\r\n sendMessage('Ok');\r\n // 进行更新检查等操作\r\n reloadApp(options, status);\r\n },\r\n};\r\n// 连接服务地址socketUrl，?http://localhost:8080，本地服务地址\r\nsocket(socketUrl, onSocketMessage);\r\n\r\nfunction reloadApp() {\r\n\tif (hot) {\r\n log.info('[WDS] App hot update...');\r\n\r\n // hotEmitter其实就是EventEmitter的实例\r\n var hotEmitter = require('webpack/hot/emitter');\r\n hotEmitter.emit('webpackHotUpdate', currentHash);\r\n }\r\n}\r\n```\r\n\r\n`socket`方法建立了`websocket`和服务端的连接，并注册了 2 个监听事件。\r\n\r\n* `hash`事件，更新最新一次打包后的`hash`值。\r\n* `ok`事件，进行热更新检查。\r\n\r\n热更新检查事件是调用`reloadApp`方法。比较奇怪的是，这个方法又利用`node.js`的`EventEmitter`，发出`webpackHotUpdate`消息。这是为什么？为什么不直接进行检查更新呢？\r\n\r\n个人理解就是为了更好的维护代码，以及职责划分的更明确。`websocket`仅仅用于客户端（浏览器）和服务端进行通信。而真正做事情的活还是交回给了`webpack`。\r\n\r\n那`webpack`怎么做的呢？再来回忆下第 2 步。入口文件还有一个文件没有讲到，就是：\r\n\r\n```\r\n'xxx/node_modules/webpack/hot/dev-server.js'\r\n```\r\n\r\n这个文件的代码同样会被打包到`bundle.js`中，运行在浏览器中。这个文件做了什么就显而易见了吧！先瞄一眼代码：\r\n\r\n```javascript\r\n// node_modules/webpack/hot/dev-server.js\r\nvar check = function check() {\r\n module.hot.check(true)\r\n .then(function(updatedModules) {\r\n // 容错，直接刷新页面\r\n if (!updatedModules) {\r\n window.location.reload();\r\n return;\r\n }\r\n\r\n // 热更新结束，打印信息\r\n if (upToDate()) {\r\n log(\"info\", \"[HMR] App is up to date.\");\r\n }\r\n })\r\n .catch(function(err) {\r\n window.location.reload();\r\n });\r\n};\r\n\r\nvar hotEmitter = require(\"./emitter\");\r\nhotEmitter.on(\"webpackHotUpdate\", function(currentHash) {\r\n lastHash = currentHash;\r\n check();\r\n});\r\n```\r\n\r\n这里`webpack`监听到了`webpackHotUpdate`事件，并获取最新了最新的`hash`值，然后终于进行检查更新了。检查更新呢调用的是`module.hot.check`方法。那么问题又来了，`module.hot.check`又是哪里冒出来了的！答案是`HotModuleReplacementPlugin`搞得鬼。这里留个疑问，继续往下看。\r\n\r\n### 6. HotModuleReplacementPlugin\r\n\r\n前面好像一直是`webpack-dev-server`做的事，那`HotModuleReplacementPlugin`在热更新过程中又做了什么伟大的事业呢？\r\n\r\n首先你可以对比下，配置热更新和不配置时`bundle.js`的区别。内存中看不到？直接执行`webpack`命令就可以看到生成的`bundle.js`文件啦。不要用`webpack-dev-server`启动就好了。\r\n\r\n（1）没有配置的。\r\n\r\n![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/12/1/16ec0c9e8fd12349~tplv-t2oaga2asx-zoom-in-crop-mark:3024:0:0:0.awebp)\r\n（2）配置了`HotModuleReplacementPlugin`或`--hot`的。\r\n\r\n![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/12/1/16ec0c90092fa0ac~tplv-t2oaga2asx-zoom-in-crop-mark:3024:0:0:0.awebp)\r\n哦~ 我们发现`moudle`新增了一个属性为`hot`，再看`hotCreateModule`方法。这不就找到`module.hot.check`是哪里冒出来的。\r\n\r\n![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/12/1/16ec0dc36018973f~tplv-t2oaga2asx-zoom-in-crop-mark:3024:0:0:0.awebp)\r\n\r\n经过对比打包后的文件，`__webpack_require__`中的`moudle`以及代码行数的不同。我们都可以发现`HotModuleReplacementPlugin`原来也是默默的塞了很多代码到`bundle.js`中呀。这和第 2 步骤很是相似哦！为什么，因为检查更新是在浏览器中操作呀。这些代码必须在运行时的环境。\r\n\r\n你也可以直接看浏览器`Sources`下的代码，会发现`webpack`和`plugin`偷偷加的代码都在哦。在这里调试也很方便。\r\n\r\n![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/12/1/16ec0d4634af2b3c~tplv-t2oaga2asx-zoom-in-crop-mark:3024:0:0:0.awebp)\r\n`HotModuleReplacementPlugin`如何做到的？这里我就不讲了，因为这需要你对`tapable`以及`plugin`机制有一定了解，可以看下我写的文章[Webpack插件机制之Tapable-源码解析](https://juejin.cn/post/6844904004435050503)。当然你也可以选择跳过，只关心热更新机制即可，毕竟信息量太大。\r\n\r\n### 7. moudle.hot.check 开始热更新\r\n\r\n通过第 6 步，我们就可以知道`moudle.hot.check`方法是如何来的啦。那都做了什么？之后的源码都是`HotModuleReplacementPlugin`塞入到`bundle.js`中的哦，我就不写文件路径了。\r\n\r\n* 利用上一次保存的`hash`值，调用`hotDownloadManifest`发送`xxx/hash.hot-update.json`的`ajax`请求；\r\n* 请求结果获取热更新模块，以及下次热更新的`Hash` 标识，并进入热更新准备阶段。\r\n\r\n```abnf\r\nhotAvailableFilesMap = update.c; // 需要更新的文件\r\nhotUpdateNewHash = update.h; // 更新下次热更新hash值\r\nhotSetStatus(\"prepare\"); // 进入热更新准备状态\r\n```\r\n\r\n* 调用`hotDownloadUpdateChunk`发送`xxx/hash.hot-update.js` 请求，通过`JSONP`方式。\r\n\r\n```javascript\r\nfunction hotDownloadUpdateChunk(chunkId) {\r\n var script = document.createElement(\"script\");\r\n script.charset = \"utf-8\";\r\n script.src = __webpack_require__.p + \"\" + chunkId + \".\" + hotCurrentHash + \".hot-update.js\";\r\n if (null) script.crossOrigin = null;\r\n document.head.appendChild(script);\r\n }\r\n```\r\n\r\n这个函数体为什么要单独拿出来，因为这里要解释下为什么使用`JSONP`获取最新代码？主要是因为`JSONP`获取的代码可以直接执行。为什么要直接执行？我们来回忆下`/hash.hot-update.js`的代码格式是怎么样的。\r\n\r\n![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/12/1/16ec04316d6ac5e3~tplv-t2oaga2asx-zoom-in-crop-mark:3024:0:0:0.awebp)\r\n\r\n可以发现，新编译后的代码是在一个`webpackHotUpdate`函数体内部的。也就是要立即执行`webpackHotUpdate`这个方法。\r\n\r\n再看下`webpackHotUpdate`这个方法。\r\n\r\n```ada\r\nwindow[\"webpackHotUpdate\"] = function (chunkId, moreModules) {\r\n hotAddUpdateChunk(chunkId, moreModules);\r\n} ;\r\n```\r\n\r\n* `hotAddUpdateChunk`方法会把更新的模块`moreModules`赋值给全局全量`hotUpdate`。\r\n* `hotUpdateDownloaded`方法会调用`hotApply`进行代码的替换。\r\n\r\n```reasonml\r\nfunction hotAddUpdateChunk(chunkId, moreModules) {\r\n // 更新的模块moreModules赋值给全局全量hotUpdate\r\n for (var moduleId in moreModules) {\r\n if (Object.prototype.hasOwnProperty.call(moreModules, moduleId)) {\r\n\t hotUpdate[moduleId] = moreModules[moduleId];\r\n }\r\n }\r\n // 调用hotApply进行模块的替换\r\n hotUpdateDownloaded();\r\n}\r\n```\r\n\r\n### 8. hotApply 热更新模块替换\r\n\r\n热更新的核心逻辑就在`hotApply`方法了。 `hotApply`代码有将近 400 行，还是挑重点讲了，看哭😭\r\n\r\n#### ①删除过期的模块，就是需要替换的模块\r\n\r\n通过`hotUpdate`可以找到旧模块\r\n\r\n```cpp\r\nvar queue = outdatedModules.slice();\r\nwhile (queue.length > 0) {\r\n moduleId = queue.pop();\r\n // 从缓存中删除过期的模块\r\n module = installedModules[moduleId];\r\n // 删除过期的依赖\r\n delete outdatedDependencies[moduleId];\r\n\r\n // 存储了被删掉的模块id，便于更新代码\r\n outdatedSelfAcceptedModules.push({\r\n module: moduleId\r\n });\r\n}\r\n```\r\n\r\n#### ②将新的模块添加到 modules 中\r\n\r\n```inform7\r\nappliedUpdate[moduleId] = hotUpdate[moduleId];\r\nfor (moduleId in appliedUpdate) {\r\n if (Object.prototype.hasOwnProperty.call(appliedUpdate, moduleId)) {\r\n modules[moduleId] = appliedUpdate[moduleId];\r\n }\r\n}\r\n```\r\n\r\n#### ③通过\\_\\_webpack\\_require\\_\\_执行相关模块的代码\r\n\r\n```abnf\r\nfor (i = 0; i < outdatedSelfAcceptedModules.length; i++) {\r\n var item = outdatedSelfAcceptedModules[i];\r\n moduleId = item.module;\r\n try {\r\n // 执行最新的代码\r\n __webpack_require__(moduleId);\r\n } catch (err) {\r\n // ...容错处理\r\n }\r\n}\r\n\r\n```\r\n\r\n`hotApply`的确比较复杂，知道大概流程就好了，这一小节，要求你对webpack打包后的文件如何执行的有一些了解，大家可以自去看下。\r\n\r\n### 总结\r\n还是以阅读源码的形式画的图，①-④的小标记，是文件发生变化的一个流程。\r\n\r\n![](https://foruda.gitee.com/images/1681014860649655814/ea9d055f_7819612.png)\r\n\r\n### 参考文档\r\n- [轻松理解webpack热更新原理](https://juejin.cn/post/6844904008432222215)\r\n- [websocket基础知识了解](https://www.ruanyifeng.com/blog/2017/05/websocket.html)\r\n- [tapable: Webpack插件机制之Tapable-源码解析](https://juejin.cn/post/6844904004435050503)\r\n* [Webpack Hot Module Replacement 的原理解析](https://github.com/Jocs/jocs.github.io/issues/15)\r\n* [看完这篇，面试再也不怕被问 Webpack 热更新](https://juejin.cn/post/6844903953092591630)\r\n- [Webpack HMR 原理解析](https://zhuanlan.zhihu.com/p/30669007)\r\n\r\n",{"_54":535,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/267/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/267/timeline",{"_54":538,"_56":57,"_58":539,"_60":540,"_62":541,"_64":542,"_66":543,"_68":544,"_70":545,"_72":546,"_74":547,"_107":548,"_127":128,"_129":26,"_130":-5,"_131":550,"_133":551,"_155":148,"_149":553,"_151":554,"_154":-5,"_158":159,"_160":555,"_165":-5,"_166":556,"_168":557,"_180":559,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/253","https://api.github.com/repos/pro-collection/interview-question/issues/253/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/253/comments","https://api.github.com/repos/pro-collection/interview-question/issues/253/events","https://github.com/pro-collection/interview-question/issues/253",1655615141,"I_kwDOJGDC6c5irq6l",253,"如果用户说 web 应用感觉很反应慢或者卡顿，该如何排查？",{"_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},[549],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":552,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-04-05T13:23:29Z","2023-09-09T06:18:59Z",{"_162":148,"_163":148,"_164":148},"### 如果用户觉得 web 应用反应卡顿，主要从哪几个方面来排查？\r\n\r\n- 加载慢\r\n - 资源下载慢\r\n - 首屏并发请求资源过多\r\n - 首屏接口慢\r\n - 首屏对应的 JS 执行慢\r\n - 首屏渲染慢\r\n - 首屏加载静态资源过大\r\n - .......\r\n- 执行过程慢\r\n - 接口慢\r\n - long tasks 太多, 阻塞 JS 执行\r\n - 内存泄漏\r\n - 重绘重排过多\r\n - 关键节点没有加节流防抖\r\n - .......\r\n\r\n\r\n### 主要排查手段有哪些\r\n- **通过建立性能监控指标**: 通过真实用户数据反馈，来判断用户是否卡顿，包含网络监控、运行时性能监控\r\n\r\n- **Chrome devtools: NetWork** 主要排查网络问题\r\n $\"image\"$ \r\n\r\n- **Chrome devtools: Performance** 主要细查性能运行时性能，包含了 long tasks、render 次数、重排重绘、执行时间线、阻塞场景\r\n $\"image\"$ \r\n\r\n- **Chrome devtools: Performance monitor** 主要监控用户运行时性能，看看是否有内存泄露\r\n $\"image\"$ \r\n\r\n- **React Developer Tools**: 可以用于追踪 react 应用性能、渲染次数、重排重绘\r\n![image](https://user-images.githubusercontent.com/22188674/229801498-3cc4fc25-64a5-4b9e-ace8-5ed7b96e4ac2.png)\r\n \r\n- **Lighthouse**: 全面分析网页性能的一个工具、支持浏览器插件 \r\n![image](https://user-images.githubusercontent.com/22188674/229803209-505d01da-d780-4a3e-abe7-e56cd942a64b.png)\r\n\r\n- **webpack-bundle-analyzer**: 进行产物依赖分析、包大小分析\r\n\r\n- **抓包**: 通过抓包的方式，看看线上请求分析、请求模拟、网络劫持之后仅仅看 JS 执行时间\r\n\r\n- **E2E测试**: 通过 E2E 进行性能预检，每次上线前进行一系列系统操作，看看时间耗时和线上耗时波动\r\n\r\n\r\n### 主要解决办法和思路\r\n\r\n**首屏加载慢的方向** \r\n- 资源加载方向\r\n - 使用 `tree shaking` 减少包体积\r\n - 代码压缩和混淆\r\n - 对于高版本浏览器，直接使用 ES6 语法，低版本浏览器再使用 ES5（es6 语法代码量会比编译成 es5 代码量小很多，且执行速度也快）\r\n - 使用 `split chunks` 进行大包拆分、小包复用\r\n - 使用 `gzip` \r\n - 使用图片压缩\r\n - 使用雪碧图\r\n - 图标使用 `iconfont` 加载\r\n - 懒加载，仅加载首屏必要资源\r\n - 使用 `tailwindcss` 等技术，复用 css \r\n - 使用 `微前端` 技术，首屏仅加载当前子应用页面，可以做到只加载整站很少的一部分代码\r\n - 首屏非必要依赖尽量延后到 FMP 或者 TTI 之后再加载\r\n - 组件微前端化\r\n \r\n- 渲染方向\r\n - 尽量减少重排重绘\r\n - 减少重复渲染（useMemo、useCallback、memo 等）\r\n - 减少 setState 次数（多次 setState 可以合并为一次）\r\n - 尽量减少 dom 节点深度\r\n \r\n- 网络方向\r\n - 使用流式服务端渲染，可以查看文档：https://juejin.cn/post/6953819275941380109\r\n - 使用服务端渲染，减少首屏请求\r\n - 使用 SSG 静态站点生成\r\n - 首屏必要数据，不作客户端请求，用后端模板注入\r\n - 使用 BFF 进行请求聚合\r\n - 使用 CDN 进行网络请求分发\r\n - DNS Prefetch \r\n - 资源预加载（在闲暇时间加载后续页面所需要的资源和接口，例如：link rel preload）\r\n - 启用 HTTP2 多路复用\r\n - 在业务逻辑上，首屏必要接口提前（例如在 html 加载的那一瞬间，利用一个非常小的 js 文件将首屏需要的请求发送出去, 然后缓存下来，到业务使用的时候直接就使用即可）\r\n - 使用缓存技术缓存资源与请求：强缓存、协商缓存、离线缓存、Service Worker 缓存、后端业务缓存\r\n \r\n**运行时卡顿方向**\r\n- 查看是否存在有有 `long tasks`，有计划的拆解 `long tasks`\r\n- 解决项目中复杂度问题： https://www.jianshu.com/p/ffbb25380904\r\n- 排查项目是否有内存泄露\r\n- 排查特定业务流程是否有慢接口\r\n- 高复杂计算逻辑放在 service worker 处理\r\n\r\n\r\n\r\n### 参考文档\r\n- https://juejin.cn/post/7096144248713510943\r\n- https://juejin.cn/post/6882936217609732110\r\n- https://juejin.cn/post/7119074496610304031\r\n- https://juejin.cn/post/7159807927908302884\r\n",{"_54":558,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/253/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/253/timeline",{"_54":561,"_56":57,"_58":562,"_60":563,"_62":564,"_64":565,"_66":566,"_68":567,"_70":568,"_72":569,"_74":570,"_107":571,"_127":128,"_129":26,"_130":-5,"_131":578,"_133":579,"_155":185,"_149":581,"_151":582,"_154":-5,"_158":159,"_160":583,"_165":-5,"_166":584,"_168":585,"_180":587,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/249","https://api.github.com/repos/pro-collection/interview-question/issues/249/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/249/comments","https://api.github.com/repos/pro-collection/interview-question/issues/249/events","https://github.com/pro-collection/interview-question/issues/249",1651174324,"I_kwDOJGDC6c5iauu0",249,"[webpack] 如果解决重复引用 node_modules 里面的不同版本的包(包重复问题)",{"_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},[572,573],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":574,"_68":575,"_54":576,"_113":577,"_115":125,"_117":26,"_118":126},5342931240,"LA_kwDOJGDC6c8AAAABPnapKA","https://api.github.com/repos/pro-collection/interview-question/labels/%E7%BE%8E%E5%9B%A2","美团",[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":580,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-04-03T01:18:02Z","2023-04-26T15:20:48Z",{"_162":148,"_163":148,"_164":148},"解决重复引用 `node_modules` 中不同版本的包的问题，可以通过以下几种方式：\n\n**1.使用 npm 或者 yarn 的工具进行依赖的版本控制，尽量避免引用不同版本的同一个依赖库**。在 package.json 文件中使用 \"^\"、\"~\"、\">=\" 等方式指定依赖版本，可以有效减少不同版本的包冲突问题。\n\n**2.使用 webpack 的 resolve.alias 配置选项**，将需要共享的模块指定到一个目录下，然后在其它模块中使用别名引用该模块。例如，将需要共享的模块指定到 src/shared 目录下，然后在其它模块中使用别名 @shared 引用该模块，这样就可以保证在不同模块中引用相同的依赖库。\n假设我们在项目中同时依赖了两个库：`lodash` 和 `lodash-es`，并且它们分别被安装在了不同的目录下，如下所示：\n\n```\nCopy codenode_modules/\n├── lodash/\n└── lodash-es/\n```\n\n我们需要在项目中同时引用这两个库，但是如果我们在代码中分别使用 `import _ from 'lodash'` 和 `import _ from 'lodash-es'`，那么 webpack 会将它们打包成两个独立的模块，导致代码体积变大。\n\n为了解决这个问题，我们可以通过 `resolve.alias` 配置项将它们指向同一个模块。具体做法是在 webpack 配置文件中添加以下内容：\n\n```js\nmodule.exports = {\n // ...\n resolve: {\n alias: {\n 'lodash-es': 'lodash'\n }\n }\n}\n```\n\n这样一来，当我们在代码中使用 `import _ from 'lodash-es'` 时，webpack 会自动将它解析成对 `lodash` 的引用，从而避免了重复打包的问题。\n\n**3.使用 webpack 的 ProvidePlugin 插件**，将需要共享的模块注入到全局作用域中，这样就可以在不同模块中共享相同的依赖库。例如，在 webpack 配置文件中添加以下代码：\n\n```javascript\nconst webpack = require('webpack');\n\nmodule.exports = {\n // ...\n plugins: [\n new webpack.ProvidePlugin({\n $: 'jquery',\n jQuery: 'jquery',\n 'window.jQuery': 'jquery',\n }),\n ],\n};\n```\n\n这样在不同模块中就可以使用 $、jQuery、window.jQuery 全局变量引用 jquery 依赖库，避免了重复引用不同版本的 jquery 包的问题。\n\n**4.使用 webpack 的 resolve.modules 配置选项**，将 node\\_modules 目录移动到项目根目录之外，然后在 resolve.modules 中添加该目录的绝对路径，这样就可以解决不同模块中引用相同依赖库不同版本的问题。例如，在 webpack 配置文件中添加以下代码：\n\n```javascript\nconst path = require('path');\n\nmodule.exports = {\n // ...\n resolve: {\n modules: [\n path.resolve(__dirname, 'src'),\n 'node_modules',\n ],\n },\n};\n```\n\n这样 webpack 在查找依赖库的时候，会先在项目根目录下的 src 目录中查找，如果没有找到再去 node\\_modules 目录中查找，避免了不同模块中引用相同依赖库不同版本的问题。\n",{"_54":586,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/249/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/249/timeline",{"_54":589,"_56":57,"_58":590,"_60":591,"_62":592,"_64":593,"_66":594,"_68":595,"_70":596,"_72":597,"_74":598,"_107":599,"_127":128,"_129":26,"_130":-5,"_131":606,"_133":607,"_155":148,"_149":609,"_151":610,"_154":-5,"_158":159,"_160":611,"_165":-5,"_166":612,"_168":613,"_180":615,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/247","https://api.github.com/repos/pro-collection/interview-question/issues/247/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/247/comments","https://api.github.com/repos/pro-collection/interview-question/issues/247/events","https://github.com/pro-collection/interview-question/issues/247",1651170765,"I_kwDOJGDC6c5iat3N",247,"[webpack] 是如何实现 treeShaking 的",{"_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},[600,601],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":602,"_68":603,"_54":604,"_113":605,"_115":125,"_117":26,"_118":126},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","阿里巴巴",[],{"_54":240,"_64":241,"_58":242,"_66":243,"_68":244,"_70":245,"_72":246,"_118":247,"_143":608,"_145":249,"_147":148,"_127":128,"_149":250,"_151":251,"_153":-5,"_154":-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},"2023-04-03T01:10:58Z","2023-04-03T01:10:59Z",{"_162":148,"_163":148,"_164":148},"webpack实现tree shaking的原理是基于ES6模块化语法的静态特性。\n\n在编译阶段，Webpack会根据模块的依赖关系，通过AST（抽象语法树）进行静态分析，识别出那些代码块（函数、变量、对象等）被引用并且使用了。然后将这些代码块打包输出到最终的打包文件中。在这个过程中，Webpack会自动将未被引用的代码块进行剔除，这个过程就是tree shaking。\n\n具体来说，当Webpack在打包时遇到一个ES6模块导入语句（import），它会自动去加载这个模块并分析其导出对象。然后它会分析项目中哪些导出对象被引用了。如果一个导出对象没有被引用，那么Webpack会直接把它从最终的代码中剔除掉。\n\n需要注意的是，tree shaking只对ES6模块生效，对于CommonJS等其他模块化规范，由于其动态加载特性，无法在静态分析阶段确定哪些代码块被引用，因此无法进行tree shaking。\n\n另外，为了使Webpack能够正确识别和剔除未引用的代码块，开发者也需要做出一定的努力，例如将代码编写为纯函数的形式，避免使用全局变量等副作用等。\n\n具体哪些会导致 tree shaking 失效，可以看这个文章：https://github.com/pro-collection/interview-question/issues/235\n",{"_54":614,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/247/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/247/timeline",{"_54":617,"_56":57,"_58":618,"_60":619,"_62":620,"_64":621,"_66":622,"_68":623,"_70":624,"_72":625,"_74":626,"_107":627,"_127":128,"_129":26,"_130":-5,"_131":630,"_133":631,"_155":148,"_149":633,"_151":633,"_154":-5,"_158":159,"_160":634,"_165":-5,"_166":635,"_168":636,"_180":638,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/246","https://api.github.com/repos/pro-collection/interview-question/issues/246/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/246/comments","https://api.github.com/repos/pro-collection/interview-question/issues/246/events","https://github.com/pro-collection/interview-question/issues/246",1651163110,"I_kwDOJGDC6c5iar_m",246,"[webpack] loader 和 plugin 有啥区别",{"_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},[628,629],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":602,"_68":603,"_54":604,"_113":605,"_115":125,"_117":26,"_118":126},[],{"_54":240,"_64":241,"_58":242,"_66":243,"_68":244,"_70":245,"_72":246,"_118":247,"_143":632,"_145":249,"_147":148,"_127":128,"_149":250,"_151":251,"_153":-5,"_154":-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},"2023-04-03T00:55:06Z",{"_162":148,"_163":148,"_164":148},"在Webpack中，Loader和Plugin是两个不同的概念，它们的作用和使用方式也有所不同。\n\nLoader用于对源代码文件进行转换和处理，而Plugin用于对Webpack的编译过程进行扩展和增强。\n\n* **Loader**\n\nLoader是Webpack中的一个核心概念，它用于处理源代码文件，将它们转换成Webpack可处理的模块。Webpack在处理代码模块的过程中，会根据模块的类型来选择相应的Loader进行处理，例如，处理CSS文件需要使用css-loader，处理图片需要使用file-loader等。使用Loader可以实现代码转换、文件处理、代码压缩等功能。\n\nLoader的使用方式是在Webpack的配置文件中定义module.rules属性，它是一个数组，每个元素是一个对象，用于描述如何处理特定类型的文件。一个Loader对象通常包括以下几个属性：\n\n* test：用于匹配需要处理的文件类型，通常是一个正则表达式。\n* use：指定需要使用的Loader，可以是一个字符串或一个数组，数组中的每个元素都是一个Loader。\n* exclude/include：指定需要排除/包含的文件夹。\n\n例如，处理CSS文件需要使用css-loader和style-loader，可以在Webpack配置文件中添加如下配置：\n\n```javascript\nmodule: {\n rules: [\n {\n test: /\\.css$/,\n use: [\"style-loader\", \"css-loader\"]\n }\n ]\n}\n```\n\n* **Plugin**\n\nPlugin是Webpack中的另一个核心概念，它用于扩展Webpack的功能。Plugin可以用于执行任意类型的任务，例如，生成HTML文件、压缩代码、提取公共代码等。使用Plugin可以实现Webpack无法处理的复杂任务。\n\nPlugin的使用方式是在Webpack的配置文件中定义plugins属性，它是一个数组，每个元素是一个Plugin实例。Plugin通常包括以下几个方法：\n\n* apply：用于安装插件，接收一个compiler对象作为参数。\n* 一些Webpack钩子函数的实现。\n\n例如，生成HTML文件需要使用HtmlWebpackPlugin，可以在Webpack配置文件中添加如下配置：\n\n```javascript\nconst HtmlWebpackPlugin = require('html-webpack-plugin');\nmodule.exports = {\n // ...\n plugins: [\n new HtmlWebpackPlugin({\n title: 'My App',\n template: './src/index.html'\n })\n ]\n};\n```\n\n\n**表格对比他们之间的差异和适用范围**\n\n|区别|Loader|Plugin|\n|---|---|---|\n|输入/输出|输入文件，输出处理后的文件|可以在Webpack构建过程中处理输出结果或做额外处理|\n|使用方式|在模块加载时直接调用|在Webpack配置中进行配置|\n|功能|用于处理某些类型的文件|可以处理打包过程的各个环节|\n|实现方式|导出一个函数|导出一个类|\n|配置方式|在Webpack配置中使用|在Webpack配置中使用|\n|作用|转换文件或模块|对整个构建过程进行自定义操作|\n|适用场景|处理各种类型的文件，如css、图片等|执行比较复杂的操作，如代码压缩、代码分割等|\n|使用方式|需要在Webpack中明确的指定|无法单独使用，必须在Webpack中明确的指定使用|\n|作用对象|针对每一个文件进行处理|针对整个构建过程进行处理|\n\n\n总体而言，Loader主要用于针对单个文件进行处理，可以根据不同文件类型来选择对应的Loader；Plugin则是针对整个构建过程进行自定义操作，比如代码压缩、分离CSS文件、创建HTML文件等。\n",{"_54":637,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/246/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/246/timeline",{"_54":640,"_56":57,"_58":641,"_60":642,"_62":643,"_64":644,"_66":645,"_68":646,"_70":647,"_72":648,"_74":649,"_107":650,"_127":128,"_129":26,"_130":-5,"_131":657,"_133":658,"_155":148,"_149":660,"_151":661,"_154":-5,"_158":159,"_160":662,"_165":-5,"_166":663,"_168":664,"_180":666,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/243","https://api.github.com/repos/pro-collection/interview-question/issues/243/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/243/comments","https://api.github.com/repos/pro-collection/interview-question/issues/243/events","https://github.com/pro-collection/interview-question/issues/243",1650984812,"I_kwDOJGDC6c5iaAds",243,"[webpack] webpack 是如何给 web 应用注入环境变量的，原理是啥",{"_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},[651,652],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":653,"_68":654,"_54":655,"_113":656,"_115":125,"_117":26,"_118":126},5312738037,"LA_kwDOJGDC6c8AAAABPKny9Q","https://api.github.com/repos/pro-collection/interview-question/labels/%E7%99%BE%E5%BA%A6","百度",[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":659,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-04-02T15:11:38Z","2023-04-02T15:11:39Z",{"_162":148,"_163":148,"_164":148},"Webpack 可以通过 DefinePlugin 插件给 web 应用注入环境变量。该插件会在编译过程中替换掉代码中指定的变量，以实现在运行时替换成环境变量的值。\n\n在 webpack 的配置文件中，需要先引入该插件，然后将需要注入的环境变量通过该插件进行配置。例如：\n\n```javascript\nconst webpack = require('webpack');\n\nmodule.exports = {\n // 其他配置\n plugins: [\n new webpack.DefinePlugin({\n 'process.env': {\n NODE_ENV: JSON.stringify('production')\n },\n API_URL: JSON.stringify('http://api.example.com')\n })\n ]\n};\n```\n\n上述配置中，定义了两个需要注入的变量，分别是 `process.env.NODE_ENV` 和 `API_URL`。其中，`process.env.NODE_ENV` 是一个常用的环境变量，用来标识当前是开发环境还是生产环境；`API_URL` 是一个自定义的环境变量，用来存储 API 的地址。\n\n在代码中使用这些环境变量时，只需要直接引用即可：\n\n```javascript\nif (process.env.NODE_ENV === 'production') {\n console.log('当前为生产环境');\n}\n\nfetch(API_URL + '/users')\n .then(response => response.json())\n .then(data => console.log(data));\n```\n\nWebpack 在编译时会将这些变量替换成对应的值，例如：\n\n```javascript\nif ('production' === 'production') {\n console.log('当前为生产环境');\n}\n\nfetch('http://api.example.com' + '/users')\n .then(response => response.json())\n .then(data => console.log(data));\n```\n\n通过这种方式，我们就可以在代码中方便地使用环境变量，同时保证了在不同环境下都能正确地使用相应的变量值。",{"_54":665,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/243/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/243/timeline",{"_54":668,"_56":57,"_58":669,"_60":670,"_62":671,"_64":672,"_66":673,"_68":674,"_70":675,"_72":676,"_74":677,"_107":678,"_127":128,"_129":26,"_130":-5,"_131":681,"_133":682,"_155":148,"_149":684,"_151":685,"_154":-5,"_158":159,"_160":686,"_165":-5,"_166":687,"_168":688,"_180":690,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/239","https://api.github.com/repos/pro-collection/interview-question/issues/239/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/239/comments","https://api.github.com/repos/pro-collection/interview-question/issues/239/events","https://github.com/pro-collection/interview-question/issues/239",1648001921,"I_kwDOJGDC6c5iOoOB",239,"如何在前端团队快速落地代码规范",{"_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},[679,680],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":200,"_68":201,"_54":202,"_113":203,"_115":125,"_117":26,"_118":126},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":683,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-03-30T17:10:42Z","2023-03-31T01:22:24Z",{"_162":148,"_163":148,"_164":148},"// todo 待整理\r\n\r\n- https://juejin.cn/post/7033210664844066853\r\n- https://juejin.cn/post/7007419705543622669\r\n- https://juejin.cn/post/7167707693333872647\r\n- https://juejin.cn/post/6844904142289240071\r\n",{"_54":689,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/239/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/239/timeline",{"_54":692,"_56":57,"_58":693,"_60":694,"_62":695,"_64":696,"_66":697,"_68":698,"_70":699,"_72":700,"_74":701,"_107":702,"_127":128,"_129":26,"_130":-5,"_131":704,"_133":705,"_155":148,"_149":707,"_151":708,"_154":-5,"_158":159,"_160":709,"_165":-5,"_166":710,"_168":711,"_180":713,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/236","https://api.github.com/repos/pro-collection/interview-question/issues/236/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/236/comments","https://api.github.com/repos/pro-collection/interview-question/issues/236/events","https://github.com/pro-collection/interview-question/issues/236",1646069439,"I_kwDOJGDC6c5iHQa_",236,"babel 的工作流程是如何的？",{"_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},[703],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":706,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-03-29T15:37:34Z","2023-03-29T15:37:35Z",{"_162":148,"_163":148,"_164":148},"Babel 是一个 JavaScript 编译器，它的主要功能是将新版本的 JavaScript 代码转换成向后兼容的代码。Babel 的工作流程可以简单概括为以下几个步骤：\n\n1. 解析：将 JavaScript 代码解析成 AST（抽象语法树）。\n\n2. 转换：对 AST 进行遍历，进行代码转换。\n\n3. 生成：将转换后的 AST 生成 JavaScript 代码。\n\n具体来说，Babel 的工作流程如下：\n\n1. Babel 使用 babylon 解析器将 JavaScript 代码解析成 AST，babylon 是一个基于 AST 的 JavaScript 解析器。\n\n2. Babel 使用 babel-traverse 遍历器对 AST 进行遍历，找到需要转换的节点，进行转换。\n\n3. Babel 使用 babel-core 转换器将 AST 转换成 JavaScript 代码。babel-core 是 babel 的核心模块，它包含了所有的转换器和插件。\n\n4. Babel 使用 babel-generator 生成器将转换后的 AST 生成 JavaScript 代码。babel-generator 是一个将 AST 转换成 JavaScript 代码的工具。\n\n在整个流程中，Babel 还会使用 babel-preset-env、babel-plugin-transform-runtime、babel-polyfill 等插件和工具来完成更加复杂的任务，如将 ES6 模块转换成 CommonJS 模块，使用 Polyfill 来实现一些新的 API 等。\n\n需要注意的是，Babel 的转换过程是有损的，转换后的代码不一定与原始代码完全相同，也可能存在性能问题。因此，在使用 Babel 进行转换时，需要谨慎选择转换的规则和插件，以确保转换后的代码正确、高效。",{"_54":712,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/236/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/236/timeline",{"_54":715,"_56":57,"_58":716,"_60":717,"_62":718,"_64":719,"_66":720,"_68":721,"_70":722,"_72":723,"_74":724,"_107":725,"_127":128,"_129":26,"_130":-5,"_131":728,"_133":729,"_155":148,"_149":731,"_151":732,"_154":-5,"_158":159,"_160":733,"_165":-5,"_166":734,"_168":735,"_180":737,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/235","https://api.github.com/repos/pro-collection/interview-question/issues/235/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/235/comments","https://api.github.com/repos/pro-collection/interview-question/issues/235/events","https://github.com/pro-collection/interview-question/issues/235",1646064267,"I_kwDOJGDC6c5iHPKL",235,"[webpack] 什么情况下 webpack treeShaking 会失效？",{"_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},[726,727],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":121,"_68":122,"_54":123,"_113":124,"_115":125,"_117":26,"_118":126},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":730,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-03-29T15:34:25Z","2023-03-29T15:34:26Z",{"_162":148,"_163":148,"_164":148},"### 以下是一些可能导致 webpack tree shaking 失效的情况\n\n1. 代码中使用了动态引入（Dynamic Imports）的语法，这种情况下，webpack 无法确定哪些代码会被使用，因此不会进行 tree shaking。\n\n2. 代码使用了函数式编程的方式，比如使用了 map、filter、reduce 等高阶函数，而这些函数很难通过静态分析确定代码的执行路径，所以可能会导致 tree shaking 失效。\n\n3. 代码中使用了 webpack 无法识别的模块系统，比如使用了 AMD 或者 CommonJS 的语法，这种情况下 webpack 也无法进行 tree shaking。\n\n4. 代码使用了 side effect，比如改变全局变量或者函数的参数，这种情况下 webpack 也无法进行 tree shaking。\n\n### 函数式编程的方式 filter 为何会导致无法 tree shaking\n\n函数式编程中常常使用高阶函数来组合函数，这种组合方式常常需要使用传递函数作为参数的方式，例如 map、filter 等高阶函数。这种情况下，如果参数传递的是一个函数表达式或者函数声明，那么无法进行 treeshaking。\n\n举个例子：\n\n```js\n// 代码中定义了一个 sum 函数\nfunction sum(a, b) {\n return a + b;\n}\n\n// 调用了 lodash 库的 filter 函数，传递一个匿名函数表达式作为参数\nimport { filter } from 'lodash';\n\nconst arr = [1, 2, 3, 4, 5];\nconst result = filter(arr, item => {\n if (item > 10) return sum(item, 1)\n else return item;\n});\n```\n上述代码中，使用了 lodash 库的 filter 函数，并且传递了一个匿名函数表达式作为参数。由于函数表达式无法被静态分析，不知道 sum 是否会被调用，因此无法进行 treeshaking，最终导致整个 sum 函数也被打包进了最终的代码中。\n\n### 为什么 commonjs 模块化会导致无法 tree shaking\n\nCommonJS 模块化语法是 Node.js 中的模块化规范，其使用了 `require()` 导入模块，使用 `module.exports` 或 `exports` 导出模块。它采用的是动态导入（require()）和同步加载的方式，这种导入方式无法在编译时确定所依赖的模块，因此在 Webpack 进行 Tree Shaking 时，这种导入方式的模块会被认为无法被静态分析，因而会被排除掉。\n\n相反，ES6 模块化语法采用的是静态导入的方式，例如 `import foo from './foo.js'`，可以在编译时分析出所依赖的模块，因此支持 Tree Shaking。\n\n因此，如果要使用 Tree Shaking，建议采用 ES6 模块化语法。如果必须使用 CommonJS 模块化规范，可以尝试使用动态导入`（import()）`语法，或者采用其他工具或手动实现 Tree Shaking。\n\n\n### side effect 是什么，为何会导致无法 tree shaking\n\n在编写 JavaScript 代码时，如果一个函数除了返回值外，还对外部的变量产生了其他的影响，比如修改了全局变量、读写了文件等操作，那么这个函数就被称为有“副作用”（side effect）。因为这种函数并不是纯函数，它可能会影响其他部分的代码执行结果，不便于优化和调试。\n\n在 Tree Shaking 的过程中，webpack 将模块打包成单独的 JavaScript 文件，它会从模块中找出哪些代码没有被使用到，并删除这些代码。但是，如果模块中存在带有副作用的代码，这些代码虽然没有被使用到，但它们仍然会被保留下来，因为这些代码可能会对其他部分的代码产生影响，因此不能简单地删除。这也是为什么带有副作用的代码会导致无法 Tree Shaking 的原因。\n\n",{"_54":736,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/235/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/235/timeline",{"_54":739,"_56":57,"_58":740,"_60":741,"_62":742,"_64":743,"_66":744,"_68":745,"_70":746,"_72":747,"_74":748,"_107":749,"_127":128,"_129":26,"_130":-5,"_131":751,"_133":752,"_155":148,"_149":754,"_151":755,"_154":-5,"_158":159,"_160":756,"_165":-5,"_166":757,"_168":758,"_180":760,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/231","https://api.github.com/repos/pro-collection/interview-question/issues/231/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/231/comments","https://api.github.com/repos/pro-collection/interview-question/issues/231/events","https://github.com/pro-collection/interview-question/issues/231",1646026621,"I_kwDOJGDC6c5iHF99",231,"不用使用 vue-cli ，如何创建一个完整的 vue 工程？",{"_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},[750],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":206,"_64":207,"_58":208,"_66":209,"_68":210,"_70":211,"_72":212,"_118":213,"_143":753,"_145":215,"_147":148,"_127":128,"_149":216,"_151":217,"_153":-5,"_154":-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},"2023-03-29T15:13:13Z","2023-03-29T15:13:14Z",{"_162":148,"_163":148,"_164":148},"这个一个较为复杂和庞大的话题，不能称之为问题，只能说它是一个话题。 \n\n主要涉及到的话题如下：\n\n1. vue 工程初始化\n2. 测试集成 \n3. UI 库绑定、基础组件使用\n4. 开发流程\n5. 代码规范（甚至包含 commit 规范）\n6. 多人协作与工作流\n7. 构建问题\n8. 上线流程\n9. 线上日志与用户反馈问题排查\n10. 性能保证\n",{"_54":759,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/231/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/231/timeline",{"_54":762,"_56":57,"_58":763,"_60":764,"_62":765,"_64":766,"_66":767,"_68":768,"_70":769,"_72":770,"_74":771,"_107":772,"_127":128,"_129":26,"_130":-5,"_131":775,"_133":776,"_155":148,"_149":778,"_151":779,"_154":-5,"_158":159,"_160":780,"_165":-5,"_166":781,"_168":782,"_180":784,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/207","https://api.github.com/repos/pro-collection/interview-question/issues/207/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/207/comments","https://api.github.com/repos/pro-collection/interview-question/issues/207/events","https://github.com/pro-collection/interview-question/issues/207",1642269410,"I_kwDOJGDC6c5h4wri",207,"使用虚拟DOM 一定会比直接操作真实 DOM 快吗？",{"_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},[773,774],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":653,"_68":654,"_54":655,"_113":656,"_115":125,"_117":26,"_118":126},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":777,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-03-27T14:59:24Z","2023-03-27T14:59:28Z",{"_162":148,"_163":148,"_164":148},"大家惯有的思维模式下，我们普遍的认为，虚拟DOM一定会比原生DOM要快的多。\n\n但实际上并不是这样。\n\n**仅从React的角度来说 : React的官网可从来都没有说过虚拟DOM会比原生操作DOM更快。**\n\n虚拟DOM和原生操作DOM谁更快这个问题。如果要我来回答的话，**一定是原生DOM比虚拟DOM更快性能更好。**\n\n值得注意的是，**虚拟DOM并不是比原生DOM快，更确切的来说，虚拟DOM是比操作不当的原生DOM快**。实际上，如果对原生DOM的操作得当的话，原生DOM的性能一定优于虚拟DOM。\n\n我们来剖析一下。\n\n### 虚拟DOM为什么而存在\n\n**其最核心的思想是提升开发效率而非提升性能**\n\n使用 React/Vue 这些框架的时候，我们不需要去考虑对DOM的操作，只需要关心数据的改变。我们以前还在使用JQ的时候，数据改变之后我们需要调用`$(\"#id\").append(node)`等操作去手动追加DOM。而在使用React/Vue之后，我们只需要关心数据的改变。至于对DOM的一系列动作，在我们的数据改变之后，React/Vue会为我们代劳。这极大程度的提升了我们的开发效率。也是React/Vue的核心思想和初衷。\n\n至于很多人都说，虚拟DOM会比操作原生DOM更快，这个说法并不全面。比如，**首次渲染或者所有节点都需要进行更新的时候。这个时候采用虚拟DOM会比直接操作原生DOM多一重构建虚拟DOM树的操作。这会更大的占用内存和延长渲染时间。**\n\n#### 举个例子\n\n**首次渲染👇不采用虚拟DOM的步骤**\n\n1. 浏览器接受绘制指令\n2. 创建所有节点\n\n**首次渲染👇采用虚拟DOM的步骤**\n\n1. 浏览器接受绘制指令\n2. 创建虚拟DOM\n3. 创建所有节点\n\n不难发现，在首次渲染的时候，采用虚拟DOM会比不采用虚拟DOM要多一个**创建虚拟DOM**的步骤。\n\n> 注意:虚拟DOM的存在，并不是免费的，比对新旧虚拟DOM树的差异会带来一定的性能开销。\n\n**虚拟DOM的优势在于我们更新节点时候。它会检查哪些节点需要更新。尽量复用已有DOM，减少DOM的删除和重新创建。并且这些操作我们是可以通过自己手动操作javascript底层api实现的。只是我们手动操作会非常耗费我们的时间和精力。这个工作由虚拟DOM代劳，会让我们开发更快速便捷。**\n\n#### 举个例子👇\n\n在采用虚拟DOM的前提下\n\n假设我们有节点A，下辖两个子节点B/C.\n\n然后我们删除了节点C\n\n这个时候会有两棵虚拟DOM树，\n\n一颗是修改前的，A->B/C。\n\n另一颗是修改后的A->B。\n\n`diff算法会去比对两颗树的差异`，然后发现A->B没有更改，那么A->B节点保留，C节点执行删除动作。\n\n那么，A->B两个节点的删除和创建渲染操作就被省略了。\n\n如果不采用虚拟DOM的话。使用JQ那时候的模板.\n\n我们可能会把A->B/C三个节点全部删除.\n\n再全都重新创建。而A->B是完全没有改动的。\n\n他们的删除和创建则完全不必要。\n\n### 框架的意义\n\n我们需要知道:不论是React还是Vue或者是Angular。这些框架本身，都是基于原生的基础上创造的。它们，底层依赖的还是javascript，并不是一门新的语言。在他们的底层逻辑下。我们使用框架所做出的一切行为，都会被框架转化为对原生DOM的操作。**框架，只是一个转化语法的工具。**\n\n既然原生DOM可以创造出这些框架。当然我们使用原生DOM自然是可以写出比这些框架更好的性能。\n\n但是:为什么对原生DOM进行操作的性能明明可以比使用框架更好。为什么大家都在使用框架，而没有人去直接对原生DOM进行操作。\n\n这背后涉及`成本`和`普适性`。\n\n如果我们直接去操作真实DOM,当然，我们可以做到在性能上比虚拟DOM更快。但问题是，技术水准能做到这个地步的人，又有多少人呢。不说比虚拟DOM快。即使是做到和虚拟DOM不分上下的性能，拥有这种水平的前端玩家，也是寥寥无几。**基于这样的客观情况下，框架的出现解决了这个问题。**\n\n框架存在的意义 : 在为我们提供只需要关注数据的前提下。框架本身已经做好了底层原理上的性能优化（包括但不限于,对DOM的调用,算法上的优化）已经是高度封装。这样就可以让我们使用一些简单的较为容易理解的技术去做我们原本做不到的事情。这其实就像调用网上的第三方包，某一个功能，自己写是写不出来，写出来性能也不会很好。但是同样的功能，我们去网上引入其他大神已经封装完成的第三方包。我们就会用，功能就可以实现并且性能上也过得去。\n\n如果让大家直接对DOM进行操作完成比框架更优秀的性能。这绝不是大多数人可以做到的。让大多数可以接受，框架需要做的，就是让大多数人使用尽量使用简单的技术，完成相对困难的操作。这是`普适性`。\n\n并且，如果完成同一个性能效果，需要我们去*精通原生javascript*和*学习框架上的一些简单的API和结构*。明显后者的学习成本更低。如果说使用框架我们所能完成的某一阶段的性能所需要的学习成本是2个月的话。那么学习javascript完成同一阶段的性能可能需要一年。\n\n框架的初衷就是让用户使用尽量简单的技术，完成相对复杂的工作并提升一定的性能 *（这其中包括但不限于:可维护性，可复用性，渲染效率等）* 。这样，即使我们的水平不是很高，使用框架以后。项目在性能上也能过得去。\n\n# 总结\n\n1. 虚拟DOM不一定会比操作原生DOM更快。\n2. 虚拟DOM的优势在于节点进行改动的时候尽量减少开销\n3. React从来没说过虚拟DOM会比原生更快。\n4. 框架的本质是提升开发效率，让我们的注意力更集中于数据\n",{"_54":783,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/207/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/207/timeline",{"_54":786,"_56":57,"_58":787,"_60":788,"_62":789,"_64":790,"_66":791,"_68":792,"_70":793,"_72":794,"_74":795,"_107":796,"_127":128,"_129":26,"_130":-5,"_131":799,"_133":800,"_155":148,"_149":802,"_151":803,"_154":-5,"_158":159,"_160":804,"_165":-5,"_166":805,"_168":806,"_180":808,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/204","https://api.github.com/repos/pro-collection/interview-question/issues/204/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/204/comments","https://api.github.com/repos/pro-collection/interview-question/issues/204/events","https://github.com/pro-collection/interview-question/issues/204",1640927038,"I_kwDOJGDC6c5hzo8-",204,"AMD 和 CMD 模块化有和区别？",{"_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},[797,798],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":200,"_68":201,"_54":202,"_113":203,"_115":125,"_117":26,"_118":126},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":801,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-03-26T14:08:39Z","2023-03-26T14:11:05Z",{"_162":148,"_163":148,"_164":148},"AMD（Asynchronous Module Definition）和CMD（Common Module Definition）都是JavaScript模块化方案。它们的主要区别在于对依赖的处理方式上不同。\n\nAMD是在require.js推广过程中诞生的，它的特点是提前执行，强调依赖前置。也就是说，在定义模块时就需要声明其所有依赖的模块。它的语法如下：\n\n```javascript\ndefine(['dependency1', 'dependency2'], function(dependency1, dependency2) {\n // 模块的定义\n});\n```\n\nCMD是在Sea.js推广过程中诞生的，它和AMD非常相似，但是更加懒惰，是依赖就近，延迟执行。也就是说，在模块中需要用到依赖时，才去引入依赖。它的语法如下：\n\n```javascript\ndefine(function(require, exports, module) {\n var dependency1 = require('dependency1');\n var dependency2 = require('dependency2');\n // 模块的定义\n});\n```\n\n简单来说，AMD是提前执行、依赖前置，CMD是延迟执行、依赖就近。两种模块化方案各有优缺点，选择哪种模块化方案需要根据实际情况和个人偏好进行考虑。",{"_54":807,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/204/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/204/timeline",{"_54":810,"_56":57,"_58":811,"_60":812,"_62":813,"_64":814,"_66":815,"_68":816,"_70":817,"_72":818,"_74":819,"_107":820,"_127":128,"_129":26,"_130":-5,"_131":823,"_133":824,"_155":148,"_149":826,"_151":827,"_154":-5,"_158":159,"_160":828,"_165":-5,"_166":829,"_168":830,"_180":832,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/203","https://api.github.com/repos/pro-collection/interview-question/issues/203/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/203/comments","https://api.github.com/repos/pro-collection/interview-question/issues/203/events","https://github.com/pro-collection/interview-question/issues/203",1640925937,"I_kwDOJGDC6c5hzorx",203,"前端模块化发展历程？",{"_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},[821,822],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},{"_66":200,"_68":201,"_54":202,"_113":203,"_115":125,"_117":26,"_118":126},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":825,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-03-26T14:06:45Z","2023-08-20T14:51:20Z",{"_162":148,"_163":148,"_164":148},"前端模块化是指在前端开发中，通过模块化的方式组织代码，将代码按照一定规则分割成不同的模块，便于管理和维护。\r\n\r\n前端模块化的发展历程如下：\r\n\r\n1. 早期，前端开发采用的是全局变量的方式进行开发，即将所有代码都放在一个文件中，通过全局变量进行交互。这种方式的问题在于，代码量较大，代码耦合度高，不易维护。\r\n\r\n2. 后来，前端开发采用了命名空间的方式进行组织代码，即将代码放在一个命名空间下，通过命名空间进行交互。这种方式解决了全局变量带来的问题，但是在开发大型应用时，仍然存在代码耦合度高、依赖管理不便等问题。\r\n\r\n3. 2009年，CommonJS提出了一种新的模块化规范，即将每个模块封装在一个独立的文件中，通过require和exports进行模块之间的依赖管理和导出。这种方式解决了前两种方式带来的问题，但是由于该规范是同步加载模块，不适用于浏览器环境。\r\n\r\n4. 2011年，AMD规范提出，即异步模块定义规范，采用异步的方式加载模块，可以在浏览器环境下使用。该规范主要是通过require和define方法进行模块之间的依赖管理和导出。\r\n\r\n5. 2013年，CommonJS和AMD的创始人合并了两种规范，提出了新的规范——CommonJS 2.0规范。该规范在CommonJS 1.0的基础上，增加了异步加载的功能，使其可以在浏览器环境下使用。\r\n\r\n6. 2014年，ES6（即ECMAScript 2015）正式发布，引入了模块化的支持，即通过import和export语句进行模块之间的依赖管理和导出。ES6的模块化规范具有更好的可读性、可维护性和性能优势，已成为前端开发的主流方式。\r\n\r\n7. 同时，还有一些第三方库，如RequireJS、SeaJS等，提供了更加灵活和可扩展的模块化方式，使得前端开发的模块化更加便捷和高效。\r\n\r\n\r\n-----------------------\r\n### 1 函数作为块\r\n\r\n最开始的时候，是以函数为块来编程，因为函数有自己的作用域，相对比较独立\r\n\r\n```js\r\nfunction add(a,b){...}\r\nfunction add1(a,b,c){...}\r\n```\r\n\r\n这种形式中，add和add1都是定义在全局作用域中的，会造成很多问题：\r\n\r\n1. 污染全局作用域，容易造成命名冲突\r\n2. 定义在全局作用域，数据不安全\r\n\r\n### 2 namespace模式\r\n\r\n使用对象作为独立块编程\r\n\r\n```js\r\nvar myModule={\r\n a:1,\r\n b:2,\r\n add:function(m,n){...}\r\n}\r\n```\r\n\r\n优点：减少了全局变量，有效解决了命名冲突\r\n\r\n缺点：\r\n\r\n1. 没有私有变量，使用起来很繁琐\r\n2. 数据不安全，模块外面可以随意修改内部的数据\r\n\r\n### 3 IIFE模式\r\n\r\n**使用立即执行函数来创建块，可以形成独立的作用域，外面无法访问，借助window对象来向外暴露接口**\r\n\r\n```js\r\n(function($){\r\n var a=1;\r\n var b=2;\r\n function add(m,n){\r\n ...\r\n }\r\n $('#id').addClass('.hehe');\r\n window.myModule={\r\n a:a,\r\n b:b,\r\n add:add\r\n }\r\n})()\r\n```\r\n\r\n优点：\r\n\r\n1. 减少了全局变量，解决了命名冲突\r\n2. 创建了独立的作用域，外部无法轻易修改内部数据\r\n\r\n缺点：\r\n\r\n**如果多个模块分布在多个js文件中，那么在html文件中就需要引入多个js文件**\r\n\r\n1. 会增加多个http请求，增加首屏的时候，降低用户体验\r\n2. **模块之间的引用关系很不明显，难以维护**\r\n\r\n\r\n### 4 CommonJS\r\n\r\n最开始出现的模块化方案是在node.js中实现的。node中的模块化方案是根据CommonJS规范实现的。\r\n\r\n**CommonJS规定每个文件就是一个模块，以同步的方式引入其他模块**\r\n\r\n```js\r\n//a.js\r\nfunction add(m,n){\r\n return m+n;\r\n}\r\nmodule.exports={add:add}\r\n\r\n\r\n//b.js\r\nconst {add} = require('./a.js');\r\nconsole.log(add(1,2)); // 3\r\n```\r\n\r\n这种方式是node端独有的，浏览器端如果想要使用，需要使用 **Browserify** 工具来解析。\r\n\r\n\r\n\r\n### 5 AMD和Require.js\r\n\r\nCommonJS模块之前是同步引入的，这在服务端是没有什么问题的，因为**文件都是保存在硬盘中，读取文件的速度是非常快的，同步加载带来的阻塞基本可以忽略不计。**\r\n\r\n但是如果在浏览器中使用CommonJS的话，因为**js文件是存在服务端需要请求获取，所以同步的方式加载会极大的阻塞页面**，显然是不可取的。\r\n\r\n于是诞生了AMD（Asynchronous Module Definition）规范，**一种异步加载的模块方案，使用回调函数来实现**。require.js实现了AMD的规范。\r\n\r\n```js\r\n//定义没有依赖的模块\r\n//a.js\r\ndefine(function(){\r\n function add(m,n){\r\n return m+n;\r\n }\r\n return {add:add}\r\n})\r\n\r\n//定义有依赖的模块\r\n//b.js\r\ndefine(['a'], function(a){\r\n const sum = a.add(1,2);\r\n return {sum:sum}\r\n})\r\n\r\n//引用模块\r\nrequire(['b'],function(b){\r\n console.log(b.sum); //3\r\n})\r\n```\r\n\r\n由上面代码分析Require.js的特点\r\n\r\n1. 依赖模块的代码都是放在回调函数中，等待模块都加载完成才执行这个回调函数，执行顺序可以保证\r\n2. **内部加载其他模块的时候，使用的是动态添加script标签的方式来实现动态加载**\r\n3. 内部需要缓存模块暴露出来的接口，避免多次执行\r\n\r\n**AMD推崇的是依赖前置，提前执行。**\r\n\r\n从上面代码可以看出，**在声明一个模块的时候，会在第一时间就将其依赖模块的内部代码执行完毕。而不是在真正使用的地方再去执行。**因此会带来一些资源浪费\r\n\r\n```js\r\ndefine(['a','b'],function(a,b){\r\n let sum = a.add(1,2);\r\n if(false){\r\n sum = b.add(1,2); //b模块是没有被使用的，应该是不需要执行模块内部代码的\r\n }\r\n return sum;\r\n})\r\n```\r\n\r\n\r\n\r\n### 6 CMD和Sea.js\r\n\r\n由于require.js自身的一些问题存在，所以后来在国内（玉伯）诞生了CMD（Common Module Definition）和Sea.js。\r\n\r\nCMD结合了CommonJS和AMD的特点，也是一种**异步**模块的方案，**提倡就近依赖，延迟执行。**\r\n\r\n**需要用到某个模块的时候，才用require引入，模块内部的代码也是在被引入的时候才会执行，声明的时候并没有执行。**\r\n\r\n语法设计上比较像CommonJS\r\n\r\n```js\r\n//定义模块 math.js\r\ndefine(function(require,exports,module){\r\n var a = require('./a.js'); // 引入模块\r\n function add(m,n){\r\n return m+n;\r\n }\r\n module.exports={\r\n add:add\r\n }\r\n});\r\n\r\n//加载模块\r\nseajs.use(['math.js'],function(math){\r\n var sum = math.add(1,2);\r\n})\r\n```\r\n\r\n看上面的代码可能会有疑问，模块是异步加载的，但是使用的时候require是同步使用的，没有回调函数，如何能够保证执行的顺序呢？这就不得不提sea.js中的静态依赖分析机制了。\r\n\r\n#### 6.1 Sea.js中的静态依赖分析机制\r\n\r\nSea.js中**模块加载的入口方法是use()方法，执行这个方法会开始加载所有的依赖模块**。然后sea.js中是就近依赖的，它是如何获取依赖模块的呢？\r\n\r\n**在define的方法中，如果传入的参数factory是一个函数，内部会执行函数的toString方法，转化成字符串，然后通过正则表达式分析字符串，获取require方法中的参数，通过路径分析去加载依赖的模块**。以此链式分析下去，边分析边加载模块，等待所有的依赖都加载完成之后，才开始调用use的回调函数，正式执行模块内代码。\r\n\r\n所以在require方法执行之前，对应的模块已经加载完成了，所以可以直接传入参数，执行模块函数体。\r\n\r\n#### 6.2 Sea.js的特点\r\n\r\n1. **就近依赖，延时执行**\r\n2. 内部拥有静态依赖分析机制，保证require之前，模块已经加载完毕，但是函数还没有执行\r\n3. 也是一种异步的模块化方案\r\n4. 内部也有缓存机制，缓存模块暴露的接口\r\n5. 内部加载模块的时候，和require.js一样，也是通过**动态增加script标签**来完成的\r\n\r\n\r\n\r\n### 7 ES Module\r\n\r\nES6开始，在语法标准上实现了模块化功能。简称ES Module\r\n\r\n**ES Module是一种静态依赖的模块化方案，模块与模块之间的依赖关系是在编译期完成连接的。**\r\n\r\n**前面所说的三种方案都是动态模块化方案，依赖模块都是动态引入的，而且模块都是一个对象。而ES Module中，模块不是一个对象，模块与模块之间也不是动态引入的，而且编译期间静态引入的，所以无法实现条件加载**\r\n\r\n```js\r\n//a.js\r\nfunction add(m,n){\r\n return m+n;\r\n}\r\nexport {add};\r\n\r\n// b.js\r\nimport {add} from './a.js';\r\nconsole.log(add(1,2)); //3\r\n```",{"_54":831,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/203/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/203/timeline",{"_54":834,"_56":57,"_58":835,"_60":836,"_62":837,"_64":838,"_66":839,"_68":840,"_70":841,"_72":842,"_74":843,"_107":844,"_127":128,"_129":26,"_130":-5,"_131":846,"_133":847,"_155":185,"_149":849,"_151":850,"_154":-5,"_158":159,"_160":851,"_165":-5,"_166":852,"_168":853,"_180":855,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/187","https://api.github.com/repos/pro-collection/interview-question/issues/187/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/187/comments","https://api.github.com/repos/pro-collection/interview-question/issues/187/events","https://github.com/pro-collection/interview-question/issues/187",1640837439,"I_kwDOJGDC6c5hzTE_",187,"前端单页应用 History 路由模式，需要如何配置 nginx？",{"_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},[845],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":848,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-03-26T09:30:59Z","2023-04-03T01:27:28Z",{"_162":148,"_163":148,"_164":148},"前端单页应用使用 History 路由模式，需要将路由的控制交给前端，而不是后端处理，因此需要配置 nginx 让其将所有请求都指向 index.html 页面，让前端来处理路由。\n\n具体配置可以参考以下 nginx 配置：\n\n```bash\nbashCopy codeserver {\n listen 80;\n server_name example.com; # 域名或 IP 地址\n\n location / {\n root /path/to/your/app; # 项目根目录\n index index.html;\n try_files $uri $uri/ /index.html; # 将所有请求都指向 index.html 页面\n }\n}\n```\n\n以上配置中，`try_files` 指令会尝试将请求映射到对应的文件，如果找不到，则会将请求转发到 `/index.html` 页面，由前端来处理路由。同时，`root` 指令需要指向前端应用的根目录。",{"_54":854,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/187/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/187/timeline",{"_54":857,"_56":57,"_58":858,"_60":859,"_62":860,"_64":861,"_66":862,"_68":863,"_70":864,"_72":865,"_74":866,"_107":867,"_127":128,"_129":26,"_130":-5,"_131":869,"_133":870,"_155":148,"_149":872,"_151":873,"_154":-5,"_158":159,"_160":874,"_165":-5,"_166":875,"_168":876,"_180":878,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/145","https://api.github.com/repos/pro-collection/interview-question/issues/145/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/145/comments","https://api.github.com/repos/pro-collection/interview-question/issues/145/events","https://github.com/pro-collection/interview-question/issues/145",1637895822,"I_kwDOJGDC6c5hoE6O",145,"实现 JS 沙盒的方式有哪些？",{"_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},[868],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":206,"_64":207,"_58":208,"_66":209,"_68":210,"_70":211,"_72":212,"_118":213,"_143":871,"_145":215,"_147":148,"_127":128,"_149":216,"_151":217,"_153":-5,"_154":-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},"2023-03-23T16:44:40Z","2023-03-23T16:45:35Z",{"_162":148,"_163":148,"_164":148},"微前端已经成为前端领域比较火爆的话题，在技术方面，微前端有一个始终绕不过去的话题就是前端沙箱\r\n\r\n### 什么是沙箱\r\n\r\n> Sandboxie(又叫沙箱、沙盘)即是一个虚拟系统程序，允许你在沙盘环境中运行浏览器或其他程序，因此运行所产生的变化可以随后删除。它创造了一个类似沙盒的独立作业环境，在其内部运行的程序并不能对硬盘产生永久性的影响。在网络安全中，沙箱指在隔离环境中，用以测试不受信任的文件或应用程序等行为的工具\r\n\r\n简单来说沙箱（sandbox）就是与外界隔绝的一个环境，内外环境互不影响，外界无法修改该环境内任何信息，沙箱内的东西单独属于一个世界。\r\n\r\n### JavaScript 的沙箱\r\n\r\n对于 JavaScript 来说，沙箱并非传统意义上的沙箱，它只是一种语法上的 Hack 写法，沙箱是一种安全机制，把一些不信任的代码运行在沙箱之内，使其不能访问沙箱之外的代码。当需要解析或着执行不可信的 JavaScript 的时候，需要隔离被执行代码的执行环境的时候，需要对执行代码中可访问对象进行限制，通常开始可以把 JavaScript 中处理模块依赖关系的闭包称之为沙箱。\r\n\r\n### JavaScript 沙箱实现\r\n\r\n我们大致可以把沙箱的实现总体分为两个部分：\r\n\r\n* 构建一个闭包环境\r\n* 模拟原生浏览器对象\r\n\r\n### 构建闭包环境\r\n\r\n我们知道 JavaScript 中，关于作用域（scope）,只有全局作用域（global scope）、函数作用域（function scope）以及从 ES6 开始才有的块级作用域（block scope）。如果要将一段代码中的变量、函数等的定义隔离出来，受限于 JavaScript 对作用域的控制，只能将这段代码封装到一个 Function 中，通过使用 function scope 来达到作用域隔离的目的。也因为需要这种使用函数来达到作用域隔离的目的方式，于是就有 IIFE（立即调用函数表达式）,这是一个被称为自执行匿名函数的设计模式\r\n\r\n```javascript\r\n (function foo(){\r\n var a = 1;\r\n console.log(a);\r\n })();\r\n // 无法从外部访问变量 name\r\nconsole.log(a) // 抛出错误：\"Uncaught ReferenceError: a is not defined\"\r\n\r\n```\r\n\r\n当函数变成立即执行的函数表达式时，表达式中的变量不能从外部访问，它拥有独立的词法作用域。不仅避免了外界访问 IIFE 中的变量，而且又不会污染全局作用域，弥补了 JavaScript 在 scope 方面的缺陷。一般常见于写插件和类库时，如 JQuery 当中的沙箱模式\r\n\r\n```javascript\r\n(function (window) {\r\n var jQuery = function (selector, context) {\r\n return new jQuery.fn.init(selector, context);\r\n }\r\n jQuery.fn = jQuery.prototype = function () {\r\n //原型上的方法，即所有jQuery对象都可以共享的方法和属性\r\n }\r\n jQuery.fn.init.prototype = jQuery.fn;\r\n window.jQeury = window.$ = jQuery; //如果需要在外界暴露一些属性或者方法，可以将这些属性和方法加到window全局对象上去\r\n})(window);\r\n\r\n```\r\n\r\n当将 IIFE 分配给一个变量，不是存储 IIFE 本身，而是存储 IIFE 执行后返回的结果。\r\n\r\n```ini\r\nvar result = (function () {\r\n var name = \"张三\";\r\n return name;\r\n})();\r\nconsole.log(result); // \"张三\"\r\n\r\n```\r\n\r\n### 原生浏览器对象的模拟\r\n\r\n模拟原生浏览器对象的目的是为了，防止闭包环境，操作原生对象。篡改污染原生环境；完成模拟浏览器对象之前我们需要先关注几个不常用的 API。\r\n\r\n#### eval\r\n\r\neval 函数可将字符串转换为代码执行，并返回一个或多个值\r\n\r\n```css\r\n var b = eval(\"({name:'张三'})\")\r\n console.log(b.name);\r\n\r\n```\r\n\r\n由于 eval 执行的代码可以访问闭包和全局范围，因此就导致了代码注入的安全问题，因为代码内部可以沿着作用域链往上找，篡改全局变量，这是我们不希望的\r\n\r\n#### new Function\r\n\r\nFunction 构造函数创建一个新的 Function 对象。直接调用这个构造函数可用动态创建函数\r\n\r\n> 语法\r\n\r\n`new Function ([arg1[, arg2[, ...argN]],] functionBody)`\r\n\r\n**arg1, arg2, ... argN** 被函数使用的参数的名称必须是合法命名的。参数名称是一个有效的 JavaScript 标识符的字符串，或者一个用逗号分隔的有效字符串的列表;例如“×”，“theValue”，或“a,b”。\r\n\r\n**functionBody** 一个含有包括函数定义的 JavaScript 语句的字符串。\r\n\r\n```javascript\r\nconst sum = new Function('a', 'b', 'return a + b');\r\n\r\nconsole.log(sum(1, 2));//3\r\n\r\n```\r\n\r\n同样也会遇到和 eval 类似的的安全问题和相对较小的性能问题。\r\n\r\n```javascript\r\nvar a = 1;\r\n\r\nfunction sandbox() {\r\n var a = 2;\r\n return new Function('return a;'); // 这里的 a 指向最上面全局作用域内的 1\r\n}\r\nvar f = sandbox();\r\nconsole.log(f())\r\n\r\n```\r\n\r\n与 eval 不同的是 Function 创建的函数只能在全局作用域中运行。它无法访问局部闭包变量，它们总是被创建于全局环境，因此在运行时它们只能访问全局变量和自己的局部变量，不能访问它们被 Function 构造器创建时所在的作用域的变量；但是，它仍然可以访问全局范围。new Function()是 eval()更好替代方案。它具有卓越的性能和安全性，但仍没有解决访问全局的问题。\r\n\r\n### with\r\n\r\nwith 是 JavaScript 中一个关键字,扩展一个语句的作用域链。它允许半沙盒执行。那什么叫半沙盒？语句将某个对象添加到作用域链的顶部，如果在沙盒中有某个未使用命名空间的变量，跟作用域链中的某个属性同名，则这个变量将指向这个属性值。如果沒有同名的属性，则将拋出 ReferenceError。\r\n\r\n```javascript\r\nfunction sandbox(o) {\r\n with (o){\r\n //a=5; \r\n c=2;\r\n d=3;\r\n console.log(a,b,c,d); // 0,1,2,3 //每个变量首先被认为是一个局部变量，如果局部变量与 obj 对象的某个属性同名，则这个局部变量会指向 obj 对象属性。\r\n }\r\n\r\n}\r\nvar f = {\r\n a:0,\r\n b:1\r\n}\r\nsandbox(f);\r\nconsole.log(f);\r\nconsole.log(c,d); // 2,3 c、d被泄露到window对象上\r\n\r\n```\r\n\r\n究其原理，`with`在内部使用`in`运算符。对于块内的每个变量访问，它都在沙盒条件下计算变量。如果条件是 true，它将从沙盒中检索变量。否则，就在全局范围内查找变量。但是 with 语句使程序在查找变量值时，都是先在指定的对象中查找。所以对于那些本来不是这个对象的属性的变量，查找起来会很慢，对于有性能要求的程序不适合（JavaScript 引擎会在编译阶段进行数项的性能优化。其中有些优化依赖于能够根据代码的词法进行静态分析，并预先确定所有变量和函数的定义位置，才能在执行过程中快速找到标识符。）。with 也会导致数据泄漏(在非严格模式下，会自动在全局作用域创建一个全局变量)\r\n\r\n### in 运算符\r\n\r\n> in 运算符能够检测左侧操作数是否为右侧操作数的成员。其中，左侧操作数是一个字符串，或者可以转换为字符串的表达式，右侧操作数是一个对象或数组。\r\n\r\n```javascript\r\nvar o = {\r\n a : 1,\r\n b : function() {}\r\n}\r\nconsole.log(\"a\" in o); //true\r\nconsole.log(\"b\" in o); //true\r\nconsole.log(\"c\" in o); //false\r\nconsole.log(\"valueOf\" in o); //返回true，继承Object的原型方法\r\nconsole.log(\"constructor\" in o); //返回true，继承Object的原型属性\r\n\r\n```\r\n\r\n### with + new Function\r\n\r\n配合 with 用法可以稍微限制沙盒作用域，先从当前的 with 提供对象查找，但是如果查找不到依然还能从上获取，污染或篡改全局环境。\r\n\r\n```javascript\r\nfunction sandbox (src) {\r\n src = 'with (sandbox) {' + src + '}'\r\n return new Function('sandbox', src)\r\n}\r\nvar str = 'let a = 1;window.name=\"张三\";console.log(a);console.log(b)'\r\nvar b = 2\r\nsandbox(str)({});\r\nconsole.log(window.name);//'张三'\r\n\r\n```\r\n\r\n### 基于 Proxy 实现的沙箱(ProxySandbox)\r\n\r\n由上部分内容思考,假如可以做到在使用`with`对于块内的每个变量访问都限制在沙盒条件下计算变量，从沙盒中检索变量。那么是否可以完美的解决JavaScript沙箱机制。\r\n\r\n使用 with 再加上 proxy 实现 JavaScript 沙箱\r\n\r\n> ES6 Proxy 用于修改某些操作的默认行为，等同于在语言层面做出修改，属于一种“元编程”（meta programming）\r\n\r\n```javascript\r\nfunction sandbox(code) {\r\n code = 'with (sandbox) {' + code + '}'\r\n const fn = new Function('sandbox', code)\r\n\r\n return function (sandbox) {\r\n const sandboxProxy = new Proxy(sandbox, {\r\n has(target, key) {\r\n return true\r\n }\r\n })\r\n return fn(sandboxProxy)\r\n }\r\n}\r\nvar a = 1;\r\nvar code = 'console.log(a)' // TypeError: Cannot read property 'log' of undefined\r\nsandbox(code)({})\r\n\r\n```\r\n\r\n我们前面提到`with`在内部使用`in`运算符来计算变量，如果条件是 true，它将从沙盒中检索变量。理想状态下没有问题，但也总有些特例独行的存在，比如 Symbol.unscopables。\r\n\r\n**Symbol.unscopables**\r\n\r\n> Symbol.unscopables 对象的 Symbol.unscopables 属性，指向一个对象。该对象指定了使用 with 关键字时，哪些属性会被 with 环境排除。\r\n\r\n```javascript\r\nArray.prototype[Symbol.unscopables]\r\n// {\r\n// copyWithin: true,\r\n// entries: true,\r\n// fill: true,\r\n// find: true,\r\n// findIndex: true,\r\n// keys: true\r\n// }\r\n\r\nObject.keys(Array.prototype[Symbol.unscopables])\r\n// ['copyWithin', 'entries', 'fill', 'find', 'findIndex', 'keys']\r\n\r\n```\r\n\r\n\r\n由此我们的代码还需要修改如下：\r\n\r\n```javascript\r\nfunction sandbox(code) {\r\n code = 'with (sandbox) {' + code + '}'\r\n const fn = new Function('sandbox', code)\r\n\r\n return function (sandbox) {\r\n const sandboxProxy = new Proxy(sandbox, {\r\n has(target, key) {\r\n return true\r\n },\r\n get(target, key) {\r\n if (key === Symbol.unscopables) return undefined\r\n return target[key]\r\n }\r\n })\r\n return fn(sandboxProxy)\r\n }\r\n}\r\nvar test = {\r\n a: 1,\r\n log(){\r\n console.log('11111')\r\n }\r\n}\r\nvar code = 'log();console.log(a)' // 1111,TypeError: Cannot read property 'log' of undefined\r\nsandbox(code)(test)\r\n\r\n```\r\n\r\nSymbol.unscopables 定义对象的不可作用属性。Unscopeable 属性永远不会从 with 语句中的沙箱对象中检索，而是直接从闭包或全局范围中检索。\r\n\r\n### 快照沙箱(SnapshotSandbox)\r\n\r\n以下是 qiankun 的 snapshotSandbox 的源码，这里为了帮助理解做部分精简及注释。\r\n\r\n```javascript\r\nfunction iter(obj, callbackFn) {\r\n for (const prop in obj) {\r\n if (obj.hasOwnProperty(prop)) {\r\n callbackFn(prop);\r\n }\r\n }\r\n}\r\n\r\n/**\r\n * 基于 diff 方式实现的沙箱，用于不支持 Proxy 的低版本浏览器\r\n */\r\nclass SnapshotSandbox {\r\n constructor(name) {\r\n this.name = name;\r\n this.proxy = window;\r\n this.type = 'Snapshot';\r\n this.sandboxRunning = true;\r\n this.windowSnapshot = {};\r\n this.modifyPropsMap = {};\r\n this.active();\r\n }\r\n //激活\r\n active() {\r\n // 记录当前快照\r\n this.windowSnapshot = {};\r\n iter(window, (prop) => {\r\n this.windowSnapshot[prop] = window[prop];\r\n });\r\n\r\n // 恢复之前的变更\r\n Object.keys(this.modifyPropsMap).forEach((p) => {\r\n window[p] = this.modifyPropsMap[p];\r\n });\r\n\r\n this.sandboxRunning = true;\r\n }\r\n //还原\r\n inactive() {\r\n this.modifyPropsMap = {};\r\n\r\n iter(window, (prop) => {\r\n if (window[prop] !== this.windowSnapshot[prop]) {\r\n // 记录变更，恢复环境\r\n this.modifyPropsMap[prop] = window[prop];\r\n\r\n window[prop] = this.windowSnapshot[prop];\r\n }\r\n });\r\n this.sandboxRunning = false;\r\n }\r\n}\r\nlet sandbox = new SnapshotSandbox();\r\n//test\r\n((window) => {\r\n window.name = '张三'\r\n window.age = 18\r\n console.log(window.name, window.age) //\t张三,18\r\n sandbox.inactive() //\t还原\r\n console.log(window.name, window.age) //\tundefined,undefined\r\n sandbox.active() //\t激活\r\n console.log(window.name, window.age) //\t张三,18\r\n})(sandbox.proxy);\r\n\r\n```\r\n\r\n快照沙箱实现来说比较简单，主要用于不支持 Proxy 的低版本浏览器，原理是基于`diff`来实现的,在子应用激活或者卸载时分别去通过快照的形式记录或还原状态来实现沙箱，snapshotSandbox 会污染全局 window。\r\n\r\n### legacySandBox\r\n\r\nqiankun 框架 singular 模式下 proxy 沙箱实现，为了便于理解，这里做了部分代码的精简和注释。\r\n\r\n```javascript\r\n//legacySandBox\r\nconst callableFnCacheMap = new WeakMap();\r\n\r\nfunction isCallable(fn) {\r\n if (callableFnCacheMap.has(fn)) {\r\n return true;\r\n }\r\n const naughtySafari = typeof document.all === 'function' && typeof document.all === 'undefined';\r\n const callable = naughtySafari ? typeof fn === 'function' && typeof fn !== 'undefined' : typeof fn ===\r\n 'function';\r\n if (callable) {\r\n callableFnCacheMap.set(fn, callable);\r\n }\r\n return callable;\r\n};\r\n\r\nfunction isPropConfigurable(target, prop) {\r\n const descriptor = Object.getOwnPropertyDescriptor(target, prop);\r\n return descriptor ? descriptor.configurable : true;\r\n}\r\n\r\nfunction setWindowProp(prop, value, toDelete) {\r\n if (value === undefined && toDelete) {\r\n delete window[prop];\r\n } else if (isPropConfigurable(window, prop) && typeof prop !== 'symbol') {\r\n Object.defineProperty(window, prop, {\r\n writable: true,\r\n configurable: true\r\n });\r\n window[prop] = value;\r\n }\r\n}\r\n\r\n\r\nfunction getTargetValue(target, value) {\r\n /*\r\n 仅绑定 isCallable && !isBoundedFunction && !isConstructable 的函数对象，如 window.console、window.atob 这类。目前没有完美的检测方式，这里通过 prototype 中是否还有可枚举的拓展方法的方式来判断\r\n @warning 这里不要随意替换成别的判断方式，因为可能触发一些 edge case（比如在 lodash.isFunction 在 iframe 上下文中可能由于调用了 top window 对象触发的安全异常）\r\n */\r\n if (isCallable(value) && !isBoundedFunction(value) && !isConstructable(value)) {\r\n const boundValue = Function.prototype.bind.call(value, target);\r\n for (const key in value) {\r\n boundValue[key] = value[key];\r\n }\r\n if (value.hasOwnProperty('prototype') && !boundValue.hasOwnProperty('prototype')) {\r\n Object.defineProperty(boundValue, 'prototype', {\r\n value: value.prototype,\r\n enumerable: false,\r\n writable: true\r\n });\r\n }\r\n\r\n return boundValue;\r\n }\r\n\r\n return value;\r\n}\r\n\r\n/**\r\n * 基于 Proxy 实现的沙箱\r\n */\r\nclass SingularProxySandbox {\r\n /** 沙箱期间新增的全局变量 */\r\n addedPropsMapInSandbox = new Map();\r\n\r\n /** 沙箱期间更新的全局变量 */\r\n modifiedPropsOriginalValueMapInSandbox = new Map();\r\n\r\n /** 持续记录更新的(新增和修改的)全局变量的 map，用于在任意时刻做 snapshot */\r\n currentUpdatedPropsValueMap = new Map();\r\n\r\n name;\r\n\r\n proxy;\r\n\r\n type = 'LegacyProxy';\r\n\r\n sandboxRunning = true;\r\n\r\n latestSetProp = null;\r\n\r\n active() {\r\n if (!this.sandboxRunning) {\r\n this.currentUpdatedPropsValueMap.forEach((v, p) => setWindowProp(p, v));\r\n }\r\n\r\n this.sandboxRunning = true;\r\n }\r\n\r\n inactive() {\r\n // console.log(' this.modifiedPropsOriginalValueMapInSandbox', this.modifiedPropsOriginalValueMapInSandbox)\r\n // console.log(' this.addedPropsMapInSandbox', this.addedPropsMapInSandbox)\r\n //删除添加的属性，修改已有的属性\r\n this.modifiedPropsOriginalValueMapInSandbox.forEach((v, p) => setWindowProp(p, v));\r\n this.addedPropsMapInSandbox.forEach((_, p) => setWindowProp(p, undefined, true));\r\n\r\n this.sandboxRunning = false;\r\n }\r\n\r\n constructor(name) {\r\n this.name = name;\r\n const {\r\n addedPropsMapInSandbox,\r\n modifiedPropsOriginalValueMapInSandbox,\r\n currentUpdatedPropsValueMap\r\n } = this;\r\n\r\n const rawWindow = window;\r\n //Object.create(null)的方式，传入一个不含有原型链的对象\r\n const fakeWindow = Object.create(null);\r\n\r\n const proxy = new Proxy(fakeWindow, {\r\n set: (_, p, value) => {\r\n if (this.sandboxRunning) {\r\n if (!rawWindow.hasOwnProperty(p)) {\r\n addedPropsMapInSandbox.set(p, value);\r\n } else if (!modifiedPropsOriginalValueMapInSandbox.has(p)) {\r\n // 如果当前 window 对象存在该属性，且 record map 中未记录过，则记录该属性初始值\r\n const originalValue = rawWindow[p];\r\n modifiedPropsOriginalValueMapInSandbox.set(p, originalValue);\r\n }\r\n\r\n currentUpdatedPropsValueMap.set(p, value);\r\n // 必须重新设置 window 对象保证下次 get 时能拿到已更新的数据\r\n rawWindow[p] = value;\r\n\r\n this.latestSetProp = p;\r\n\r\n return true;\r\n }\r\n\r\n // 在 strict-mode 下，Proxy 的 handler.set 返回 false 会抛出 TypeError，在沙箱卸载的情况下应该忽略错误\r\n return true;\r\n },\r\n\r\n get(_, p) {\r\n //避免使用 window.window 或者 window.self 逃离沙箱环境，触发到真实环境\r\n if (p === 'top' || p === 'parent' || p === 'window' || p === 'self') {\r\n return proxy;\r\n }\r\n const value = rawWindow[p];\r\n return getTargetValue(rawWindow, value);\r\n },\r\n\r\n has(_, p) { //返回boolean\r\n return p in rawWindow;\r\n },\r\n\r\n getOwnPropertyDescriptor(_, p) {\r\n const descriptor = Object.getOwnPropertyDescriptor(rawWindow, p);\r\n // 如果属性不作为目标对象的自身属性存在，则不能将其设置为不可配置\r\n if (descriptor && !descriptor.configurable) {\r\n descriptor.configurable = true;\r\n }\r\n return descriptor;\r\n },\r\n });\r\n\r\n this.proxy = proxy;\r\n }\r\n}\r\n\r\nlet sandbox = new SingularProxySandbox();\r\n\r\n((window) => {\r\n window.name = '张三';\r\n window.age = 18;\r\n window.sex = '男';\r\n console.log(window.name, window.age,window.sex) //\t张三,18,男\r\n sandbox.inactive() //\t还原\r\n console.log(window.name, window.age,window.sex) //\t张三,undefined,undefined\r\n sandbox.active() //\t激活\r\n console.log(window.name, window.age,window.sex) //\t张三,18,男\r\n})(sandbox.proxy); //test\r\n\r\n```\r\n\r\nlegacySandBox 还是会操作 window 对象，但是他通过激活沙箱时还原子应用的状态，卸载时还原主应用的状态来实现沙箱隔离的，同样会对 window 造成污染，但是性能比快照沙箱好，不用遍历 window 对象。\r\n\r\n### proxySandbox(多例沙箱)\r\n\r\n在 qiankun 的沙箱 proxySandbox 源码里面是对 fakeWindow 这个对象进行了代理，而这个对象是通过 createFakeWindow 方法得到的，这个方法是将 window 的 document、location、top、window 等等属性拷贝一份，给到 fakeWindow。\r\n\r\n源码展示：\r\n\r\n```javascript\r\n\r\nfunction createFakeWindow(global: Window) {\r\n // map always has the fastest performance in has check scenario\r\n // see https://jsperf.com/array-indexof-vs-set-has/23\r\n const propertiesWithGetter = new Map();\r\n const fakeWindow = {} as FakeWindow;\r\n\r\n /*\r\n copy the non-configurable property of global to fakeWindow\r\n see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy/handler/getOwnPropertyDescriptor\r\n > A property cannot be reported as non-configurable, if it does not exists as an own property of the target object or if it exists as a configurable own property of the target object.\r\n */\r\n Object.getOwnPropertyNames(global)\r\n .filter((p) => {\r\n const descriptor = Object.getOwnPropertyDescriptor(global, p);\r\n return !descriptor?.configurable;\r\n })\r\n .forEach((p) => {\r\n const descriptor = Object.getOwnPropertyDescriptor(global, p);\r\n if (descriptor) {\r\n const hasGetter = Object.prototype.hasOwnProperty.call(descriptor, 'get');\r\n\r\n /*\r\n make top/self/window property configurable and writable, otherwise it will cause TypeError while get trap return.\r\n see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy/handler/get\r\n > The value reported for a property must be the same as the value of the corresponding target object property if the target object property is a non-writable, non-configurable data property.\r\n */\r\n if (\r\n p === 'top' ||\r\n p === 'parent' ||\r\n p === 'self' ||\r\n p === 'window' ||\r\n (process.env.NODE_ENV === 'test' && (p === 'mockTop' || p === 'mockSafariTop'))\r\n ) {\r\n descriptor.configurable = true;\r\n /*\r\n The descriptor of window.window/window.top/window.self in Safari/FF are accessor descriptors, we need to avoid adding a data descriptor while it was\r\n Example:\r\n Safari/FF: Object.getOwnPropertyDescriptor(window, 'top') -> {get: function, set: undefined, enumerable: true, configurable: false}\r\n Chrome: Object.getOwnPropertyDescriptor(window, 'top') -> {value: Window, writable: false, enumerable: true, configurable: false}\r\n */\r\n if (!hasGetter) {\r\n descriptor.writable = true;\r\n }\r\n }\r\n\r\n if (hasGetter) propertiesWithGetter.set(p, true);\r\n\r\n // freeze the descriptor to avoid being modified by zone.js\r\n // see https://github.com/angular/zone.js/blob/a5fe09b0fac27ac5df1fa746042f96f05ccb6a00/lib/browser/define-property.ts#L71\r\n rawObjectDefineProperty(fakeWindow, p, Object.freeze(descriptor));\r\n }\r\n });\r\n\r\n return {\r\n fakeWindow,\r\n propertiesWithGetter,\r\n };\r\n}\r\n\r\n```\r\n\r\nproxySandbox 由于是拷贝复制了一份 fakeWindow，不会污染全局 window，同时支持多个子应用同时加载。详细源码请查看[：proxySandbox](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fumijs%2Fqiankun%2Fblob%2Fmaster%2Fsrc%2Fsandbox%2FproxySandbox.ts \"https://github.com/umijs/qiankun/blob/master/src/sandbox/proxySandbox.ts\")\r\n\r\n### 关于 CSS 隔离\r\n\r\n常见的有：\r\n\r\n* CSS Module\r\n* namespace\r\n* Dynamic StyleSheet\r\n* css in js\r\n* Shadow DOM 常见的我们这边不再赘述，这里我们重点提一下Shadow DO。\r\n\r\n### Shadow DOM\r\n\r\nShadow DOM 允许将隐藏的 DOM 树附加到常规的 DOM 树中——它以 shadow root 节点为起始根节点，在这个根节点的下方，可以是任意元素，和普通的 DOM 元素一样。\r\n",{"_54":877,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/145/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/145/timeline",{"_54":880,"_56":57,"_58":881,"_60":882,"_62":883,"_64":884,"_66":885,"_68":886,"_70":887,"_72":888,"_74":889,"_107":890,"_127":128,"_129":26,"_130":-5,"_131":892,"_133":893,"_155":185,"_149":895,"_151":896,"_154":-5,"_158":159,"_160":897,"_165":-5,"_166":898,"_168":899,"_180":901,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/141","https://api.github.com/repos/pro-collection/interview-question/issues/141/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/141/comments","https://api.github.com/repos/pro-collection/interview-question/issues/141/events","https://github.com/pro-collection/interview-question/issues/141",1634270758,"I_kwDOJGDC6c5haP4m",141,"如何组织 monorepo 工程？",{"_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},[891],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":894,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-03-21T16:16:01Z","2023-03-29T08:24:59Z",{"_162":148,"_163":148,"_164":148},"参考文档： \n- [pnpm + workspace + changesets 构建你的 monorepo 工程](https://juejin.cn/post/7098609682519949325)\n- [现代 Monorepo 工程技术选型，聊聊我的思考](https://juejin.cn/post/7102452341210611720)\n- [前端工程化之多个项目如何同时高效管理 — monorepo](https://juejin.cn/post/6985336835459252260)\n",{"_54":900,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/141/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/141/timeline",{"_54":903,"_56":57,"_58":904,"_60":905,"_62":906,"_64":907,"_66":908,"_68":909,"_70":910,"_72":911,"_74":912,"_107":913,"_127":128,"_129":26,"_130":-5,"_131":915,"_133":916,"_155":185,"_149":918,"_151":919,"_154":-5,"_158":159,"_160":920,"_165":-5,"_166":921,"_168":922,"_180":924,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/140","https://api.github.com/repos/pro-collection/interview-question/issues/140/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/140/comments","https://api.github.com/repos/pro-collection/interview-question/issues/140/events","https://github.com/pro-collection/interview-question/issues/140",1634236600,"I_kwDOJGDC6c5haHi4",140,"pnpm 了解多少？",{"_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},[914],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":135,"_64":136,"_58":137,"_66":138,"_68":139,"_70":140,"_72":141,"_118":142,"_143":917,"_145":146,"_147":148,"_127":128,"_149":150,"_151":152,"_153":-5,"_154":-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},"2023-03-21T16:03:46Z","2023-03-21T16:07:02Z",{"_162":148,"_163":148,"_164":148},"pnpm，英文里面的意思叫做 `performant npm` ，意味“高性能的 npm”，官网地址可以参考 [pnpm.io/。](https://link.juejin.cn?target=https%3A%2F%2Fpnpm.io%2F%25E3%2580%2582 \"https://pnpm.io/%E3%80%82\")\r\n\r\npnpm 相比较于 yarn/npm 这两个常用的包管理工具在性能上也有了极大的提升，根据目前官方提供的 [benchmark](https://link.juejin.cn?target=https%3A%2F%2Fpnpm.io%2Fbenchmarks \"https://pnpm.io/benchmarks\") 数据可以看出在一些综合场景下比 npm/yarn 快了大概两倍：\r\n\r\n![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/aa38fc979f4f4ed6a5ec4af64a73c34e~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp)\r\n\r\n在这篇文章中，将会介绍一些关于 pnpm 在依赖管理方面的优化，在 monorepo 中相比较于 yarn workspace 的应用，以及也会介绍一些 pnpm 目前存在的一些缺陷，包括讨论一下未来 pnpm 会做的一些事情。\r\n\r\n### 依赖管理\r\n\r\n这节会通过 pnpm 在依赖管理这一块的一些不同于正常包管理工具的一些优化技巧。\r\n\r\n#### hard link 机制\r\n\r\n介绍 pnpm 一定离不开的就是关于 pnpm 在安装依赖方面做的一些优化，根据前面的 benchmark 图可以看到其明显的性能提升。\r\n\r\n那么 pnpm 是怎么做到如此大的提升的呢？是因为计算机里面一个叫做 **[Hard link](https://link.juejin.cn?target=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHard_link \"https://en.wikipedia.org/wiki/Hard_link\")** 的机制，`hard link` 使得用户可以通过不同的路径引用方式去找到某个文件。pnpm 会在全局的 store 目录里存储项目 `node_modules` 文件的 `hard links` 。\r\n\r\n举个例子，例如项目里面有个 1MB 的依赖 a，在 pnpm 中，看上去这个 a 依赖同时占用了 1MB 的 node\\_modules 目录以及全局 store 目录 1MB 的空间(加起来是 2MB)，但因为 `hard link` 的机制使得两个目录下相同的 1MB 空间能从两个不同位置进行寻址，因此实际上这个 a 依赖只用占用 1MB 的空间，而不是 2MB。\r\n\r\n#### Store 目录\r\n\r\n上一节提到 store 目录用于存储依赖的 hard links，这一节简单介绍一下这个 store 目录。\r\n\r\n一般 store 目录默认是设置在 `${os.homedir}/.pnpm-store` 这个目录下，具体可以参考 `@pnpm/store-path` 这个 pnpm 子包中的代码:\r\n\r\n```js\r\nconst homedir = os.homedir()\r\nif (await canLinkToSubdir(tempFile, homedir)) {\r\n await fs.unlink(tempFile)\r\n // If the project is on the drive on which the OS home directory\r\n // then the store is placed in the home directory\r\n return path.join(homedir, relStore, STORE_VERSION)\r\n}\r\n\r\n```\r\n\r\n当然用户也可以在 `.npmrc` 设置这个 store 目录位置，不过一般而言 store 目录对于用户来说感知程度是比较小的。\r\n\r\n因为这样一个机制，导致每次安装依赖的时候，如果是个相同的依赖，有好多项目都用到这个依赖，那么这个依赖实际上最优情况(即版本相同)只用安装一次。\r\n\r\n如果是 npm 或 yarn，那么这个依赖在多个项目中使用，在每次安装的时候都会被重新下载一次。\r\n\r\n![03](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9ba60f4713bc46318ee139d3b8a9bc82~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp)\r\n\r\n如图可以看到在使用 pnpm 对项目安装依赖的时候，如果某个依赖在 sotre 目录中存在了话，那么就会直接从 store 目录里面去 hard-link，避免了二次安装带来的时间消耗，如果依赖在 store 目录里面不存在的话，就会去下载一次。\r\n\r\n当然这里你可能也会有问题：如果安装了很多很多不同的依赖，那么 store 目录会不会越来越大？\r\n\r\n答案是当然会存在，针对这个问题，pnpm 提供了一个命令来解决这个问题: [pnpm store | pnpm](https://link.juejin.cn?target=https%3A%2F%2Fpnpm.io%2Fcli%2Fstore \"https://pnpm.io/cli/store\")。\r\n\r\n同时该命令提供了一个选项，使用方法为 `pnpm store prune` ，它提供了一种用于删除一些不被全局项目所引用到的 packages 的功能，例如有个包 `axios@1.0.0` 被一个项目所引用了，但是某次修改使得项目里这个包被更新到了 `1.0.1` ，那么 store 里面的 1.0.0 的 axios 就就成了个不被引用的包，执行 `pnpm store prune` 就可以在 store 里面删掉它了。\r\n\r\n该命令推荐偶尔进行使用，但不要频繁使用，因为可能某天这个不被引用的包又突然被哪个项目引用了，这样就可以不用再去重新下载这个包了。\r\n\r\n#### node\\_modules 结构\r\n\r\n在 pnpm 官网有一篇很经典的文章，关于介绍 pnpm 项目的 node\\_modules 结构: [Flat node\\_modules is not the only way | pnpm](https://link.juejin.cn?target=https%3A%2F%2Fpnpm.io%2Fblog%2F2020%2F05%2F27%2Fflat-node-modules-is-not-the-only-way \"https://pnpm.io/blog/2020/05/27/flat-node-modules-is-not-the-only-way\")。\r\n\r\n在这篇文章中介绍了 pnpm 目前的 node\\_modules 的一些文件结构，例如在项目中使用 pnpm 安装了一个叫做 `express` 的依赖，那么最后会在 node\\_modules 中形成这样两个目录结构:\r\n\r\n```bash\r\nnode_modules/express/...\r\nnode_modules/.pnpm/express@4.17.1/node_modules/xxx\r\n\r\n```\r\n\r\n其中第一个路径是 nodejs 正常寻找路径会去找的一个目录，如果去查看这个目录下的内容，会发现里面连个 `node_modules` 文件都没有：\r\n\r\n```bash\r\n▾ express\r\n ▸ lib\r\n History.md\r\n index.js\r\n LICENSE\r\n package.json\r\n Readme.md\r\n\r\n```\r\n\r\n实际上这个文件只是个软连接，它会形成一个到第二个目录的一个软连接(类似于软件的快捷方式)，这样 node 在找路径的时候，最终会找到 .pnpm 这个目录下的内容。\r\n\r\n其中这个 `.pnpm` 是个虚拟磁盘目录，然后 express 这个依赖的一些依赖会被平铺到 `.pnpm/express@4.17.1/node_modules/` 这个目录下面，这样保证了依赖能够 require 到，同时也不会形成很深的依赖层级。\r\n\r\n在保证了 nodejs 能找到依赖路径的基础上，同时也很大程度上保证了依赖能很好的被放在一起。\r\n\r\n`pnpm` 对于不同版本的依赖有着极其严格的区分要求，如果项目中某个依赖实际上依赖的 `peerDeps` 出现了具体版本上的不同，对于这样的依赖会在虚拟磁盘目录 `.pnpm` 有一个比较严格的区分，具体可以参考: [pnpm.io/how-peers-a…](https://link.juejin.cn?target=https%3A%2F%2Fpnpm.io%2Fhow-peers-are-resolved \"https://pnpm.io/how-peers-are-resolved\") 这篇文章。\r\n\r\n综合而言，本质上 pnpm 的 `node_modules` 结构是个网状 + 平铺的目录结构。这种依赖结构主要基于软连接(即 symlink)的方式来完成。\r\n\r\n#### symlink 和 hard link 机制\r\n\r\n在前面知道了 pnpm 是通过 hardlink 在全局里面搞个 store 目录来存储 node\\_modules 依赖里面的 hard link 地址，然后在引用依赖的时候则是通过 symlink 去找到对应虚拟磁盘目录下(.pnpm 目录)的依赖地址。\r\n\r\n这两者结合在一起工作之后，假如有一个项目依赖了 `bar@1.0.0` 和 `foo@1.0.0` ，那么最后的 node\\_modules 结构呈现出来的依赖结构可能会是这样的:\r\n\r\n```bash\r\nnode_modules\r\n└── bar // symlink to .pnpm/bar@1.0.0/node_modules/bar\r\n└── foo // symlink to .pnpm/foo@1.0.0/node_modules/foo\r\n└── .pnpm\r\n ├── bar@1.0.0\r\n │ └── node_modules\r\n │ └── bar -> /bar\r\n │ ├── index.js\r\n │ └── package.json\r\n └── foo@1.0.0\r\n └── node_modules\r\n └── foo -> /foo\r\n ├── index.js\r\n └── package.json\r\n\r\n```\r\n\r\n`node_modules` 中的 bar 和 foo 两个目录会软连接到 .pnpm 这个目录下的真实依赖中，而这些真实依赖则是通过 hard link 存储到全局的 store 目录中。\r\n\r\n#### 兼容问题\r\n\r\n读到这里，可能有用户会好奇: 像 hard link 和 symlink 这种方式在所有的系统上都是兼容的吗？\r\n\r\n实际上 hard link 在主流系统上(`Unix/Win`)使用都是没有问题的，但是 symlink 即软连接的方式可能会在 windows 存在一些兼容的问题，但是针对这个问题，pnpm 也提供了对应的解决方案：\r\n\r\n在 win 系统上使用一个叫做 [junctions](https://link.juejin.cn?target=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Ffileio%2Fhard-links-and-junctions \"https://docs.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions\") 的特性来替代软连接，这个方案在 win 上的兼容性要好于 symlink。\r\n\r\n或许你也会好奇为啥 pnpm 要使用 hard links 而不是全都用 symlink 来去实现。\r\n\r\n实际上存在 store 目录里面的依赖也是可以通过软连接去找到的，nodejs 本身有提供一个叫做 `--preserve-symlinks` 的参数来支持 symlink，但实际上这个参数实际上对于 symlink 的支持并不好导致作者放弃了该方案从而采用 hard links 的方式:\r\n\r\n![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/90ad9850716547d08bfbfea212d6d653~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp)\r\n\r\n具体可以参考 [github.com/nodejs/node…](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fnodejs%2Fnode-eps%2Fissues%2F46 \"https://github.com/nodejs/node-eps/issues/46\") 该issue 讨论。\r\n\r\n### Monorepo 支持\r\n\r\n`pnpm` 在 monorepo 场景可以说算得上是个完美的解决方案了，因为其本身的设计机制，导致很多关键或者说致命的问题都得到了相当有效的解决。\r\n\r\n#### workspace 支持\r\n\r\n对于 monorepo 类型的项目，pnpm 提供了 workspace 来支持，具体可以参考官网文档: [pnpm.io/workspaces/…](https://link.juejin.cn?target=https%3A%2F%2Fpnpm.io%2Fworkspaces%2F%25E3%2580%2582 \"https://pnpm.io/workspaces/%E3%80%82\")\r\n\r\n### 痛点解决\r\n\r\nMonorepo 下被人诟病较多的问题，一般是依赖结构问题。常见的两个问题就是 `Phantom dependencies` 和 `NPM doppelgangers`，用 [rush 官网](https://link.juejin.cn?target=https%3A%2F%2Frushjs.io%2F \"https://rushjs.io/\") 的图片可以很贴切的展示着两个问题:\r\n\r\n![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/977bd60346d04cc8a4565e3e398bd962~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp)\r\n\r\n下面会针对两个问题一一介绍。\r\n\r\n#### Phantom dependencies\r\n\r\nPhantom dependencies 被称之为幽灵依赖，解释起来很简单，即某个包没有被安装(`package.json` 中并没有，但是用户却能够引用到这个包)。\r\n\r\n引发这个现象的原因一般是因为 node\\_modules 结构所导致的，例如使用 yarn 对项目安装依赖，依赖里面有个依赖叫做 foo，foo 这个依赖同时依赖了 bar，yarn 会对安装的 node\\_modules 做一个扁平化结构的处理(npm v3 之后也是这么做的)，会把依赖在 node\\_modules 下打平，这样相当于 foo 和 bar 出现在同一层级下面。那么根据 nodejs 的寻径原理，用户能 require 到 foo，同样也能 require 到 bar。\r\n\r\n```bash\r\npackage.json -> foo(bar 为 foo 依赖)\r\n\r\nnode_modules\r\n\r\n /foo\r\n\r\n /bar -> 👻依赖\r\n\r\n```\r\n\r\n那么这里这个 bar 就成了一个幽灵依赖，如果某天某个版本的 foo 依赖不再依赖 bar 或者 foo 的版本发生了变化，那么 require bar 的模块部分就会抛错。\r\n\r\n以上其实只是一个简单的例子，但是根据笔者在字节内部见到的一些 monorepo(主要为 `lerna + yarn` )项目中，这其实是个比较常见的现象，甚至有些包会直接去利用这种残缺的引入方式去减轻包体积。\r\n\r\n还有一种场景就是在 lerna + yarn workspace 的项目里面，因为 yarn 中提供了 hoist 机制(即一些底层子项目的依赖会被提升到顶层的 `node_modules` 中)，这种 phantom dependencies 会更多，一些底层的子项目经常会去 require 一些在自己里面没有引入的依赖，而直接去找顶层 node\\_modules 的依赖(nodejs 这里的寻径是个递归上下的过程)并使用。\r\n\r\n而根据前面提到的 pnpm 的 `node_modules` 依赖结构，这种现象是显然不会发生的，因为被打平的依赖会被放到 `.pnpm` 这个虚拟磁盘目录下面去，用户通过 require 是根本找不到的。\r\n\r\n> 值得一提的是，pnpm 本身其实也提供了将依赖提升并且按照 yarn 那种形式组织的 node\\_modules 结构的 Option，作者将其命名为 `--shamefully-hoist` ，即 \"羞耻的 hoist\".....\r\n\r\n#### NPM doppelgangers\r\n\r\n这个问题其实也可以说是 hoist 导致的，这个问题可能会导致有大量的依赖的被重复安装，举个例子:\r\n\r\n例如有个 package，下面依赖有 lib\\_a、lib\\_b、lib\\_c、lib\\_d，其中 a 和 b 依赖 [util\\_e@1.0.0](https://link.juejin.cn?target=mailto%3Autil_e%401.0.0 \"mailto:util_e@1.0.0\")，而 c 和 d 依赖 [util\\_e@2.0.0](https://link.juejin.cn?target=mailto%3Autil_e%402.0.0 \"mailto:util_e@2.0.0\")。\r\n\r\n那么早期 npm 的依赖结构应该是这样的:\r\n\r\n```bash\r\n- package\r\n- package.json\r\n- node_modules\r\n- lib_a\r\n - node_modules <- util_e@1.0.0\r\n- lib_b\r\n - node_modules <- util_e@1.0.0\r\n_ lib_c\r\n - node_modules <- util_e@2.0.0\r\n- lib_d\r\n - node_modules <- util_e@2.0.0\r\n\r\n```\r\n\r\n这样必然会导致很多依赖被重复安装，于是就有了 hoist 和打平依赖的操作:\r\n\r\n```bash\r\n- package\r\n- package.json\r\n- node_modules\r\n- util_e@1.0.0\r\n- lib_a\r\n- lib_b\r\n_ lib_c\r\n - node_modules <- util_e@2.0.0\r\n- lib_d\r\n - node_modules <- util_e@2.0.0\r\n\r\n```\r\n\r\n但是这样也只能提升一个依赖，如果两个依赖都提升了会导致冲突，这样同样会导致一些不同版本的依赖被重复安装多次，这里就会导致使用 npm 和 yarn 的性能损失。\r\n\r\n如果是 pnpm 的话，这里因为依赖始终都是存在 store 目录下的 hard links ，一份不同的依赖始终都只会被安装一次，因此这个是能够被彻彻底底的消除的。\r\n\r\n### 目前不适用的场景\r\n\r\n前面有提到关于 pnpm 的主要问题在于 symlink(软链接)在一些场景下会存在兼容的问题，可以参考作者在 nodejs 那边开的一个 discussion：[github.com/nodejs/node…](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fnodejs%2Fnode%2Fdiscussions%2F37509 \"https://github.com/nodejs/node/discussions/37509\")\r\n\r\n![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2fb3e4b6b5ef43dc9e8437389d2cb46e~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp)\r\n\r\n在里面作者提到了目前 nodejs 软连接不能适用的一些场景，希望 nodejs 能提供一种 link 方式而不是使用软连接，同时也提到了 pnpm 目前因为软连接而不能使用的场景:\r\n\r\n* Electron 应用无法使用 pnpm\r\n* 部署在 [lambda](https://link.juejin.cn?target=https%3A%2F%2Fdocs.aws.amazon.com%2Flambda%2Flatest%2Fdg%2Fgettingstarted-package.html \"https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-package.html\") 上的应用无法使用 pnpm\r\n\r\n笔者在字节内部使用 pnpm 时也遇到过一些 nodejs 基础库不支持 symlink 的情况导致使用 pnpm 无法正常工作，不过这些库在迭代更新之后也会支持这一特性。\r\n\r\n![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b702b38ff6704651976c4c3eab540566~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp)\r\n",{"_54":923,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/140/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/140/timeline",{"_54":926,"_56":57,"_58":927,"_60":928,"_62":929,"_64":930,"_66":931,"_68":932,"_70":933,"_72":934,"_74":935,"_107":936,"_127":128,"_129":26,"_130":-5,"_131":938,"_133":939,"_155":148,"_149":941,"_151":942,"_154":-5,"_158":159,"_160":943,"_165":-5,"_166":944,"_168":945,"_180":947,"_182":-5,"_183":-5,"_184":185},"https://api.github.com/repos/pro-collection/interview-question/issues/139","https://api.github.com/repos/pro-collection/interview-question/issues/139/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/139/comments","https://api.github.com/repos/pro-collection/interview-question/issues/139/events","https://github.com/pro-collection/interview-question/issues/139",1634219700,"I_kwDOJGDC6c5haDa0",139,"pnpm 和 npm 的区别？",{"_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},[937],{"_66":110,"_68":111,"_54":112,"_113":114,"_115":116,"_117":26,"_118":119},[],{"_54":240,"_64":241,"_58":242,"_66":243,"_68":244,"_70":245,"_72":246,"_118":247,"_143":940,"_145":249,"_147":148,"_127":128,"_149":250,"_151":251,"_153":-5,"_154":-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},"2023-03-21T15:56:45Z","2023-03-21T15:57:18Z",{"_162":148,"_163":148,"_164":148},"`pnpm` 和 `npm` 是两个不同的 JavaScript 包管理工具，它们有以下区别：\n\n1. **包的存储方式：**`npm` 将每个包都下载到项目的 `node_modules` 目录中，而 `pnpm` 会在全局安装一个存储库，并在项目中创建一个符号链接到该存储库中的每个包。\n\n2. **空间占用：** 由于 `pnpm` 使用符号链接，它的空间占用通常比 `npm` 小，因为它避免了在多个项目中重复存储相同的依赖项。\n\n3. **安装速度：** 由于 `pnpm` 在全局安装中共享依赖项，因此安装速度通常比 `npm` 更快。\n\n4. **命令行接口：**`pnpm` 的命令行接口与 `npm` 不同，但它们都提供了一组相似的命令来管理包。\n\n5. **兼容性：** 由于 `pnpm` 的存储方式不同于 `npm`，因此某些与 `npm` 兼容的工具可能无法与 `pnpm` 一起使用。\n\n总的来说，`pnpm` 与 `npm` 相比具有更小的空间占用和更快的安装速度，但由于其不同的存储方式可能会导致与某些工具的不兼容。",{"_54":946,"_171":148,"_172":148,"_173":148,"_174":148,"_175":148,"_176":148,"_177":148,"_178":148,"_179":148},"https://api.github.com/repos/pro-collection/interview-question/issues/139/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/139/timeline","pagination",{"_950":951,"_162":952},"value",5,6,"actionData","errors"]