[{"_1":2,"_1007":-5,"_1008":-5},"loaderData",{"_3":4,"_53":54},"root",{"_5":6},"clerkState",{"_7":8},"__internal_clerk_state",{"_9":10,"_25":26,"_27":28,"_29":28,"_30":24,"_31":28,"_32":28,"_33":28,"_34":28,"_35":28,"_36":28,"_37":28,"_38":28,"_39":40,"_49":28,"_50":28,"_51":24,"_52":24},"__clerk_ssr_state",{"_11":12,"_13":-5,"_14":-5,"_15":-5,"_16":-5,"_17":-5,"_18":-5,"_19":-5,"_20":-5,"_21":-5,"_22":-5,"_23":24},"tokenType","session_token","sessionClaims","sessionId","sessionStatus","userId","actor","orgId","orgRole","orgSlug","orgPermissions","factorVerificationAge","isAuthenticated",false,"__publishableKey","pk_live_Y2xlcmsucXVlc3Rpb25zLnZpc3VhbGl6ZWl0LmFwcCQ","__proxyUrl","","__domain","__isSatellite","__signInUrl","__signUpUrl","__afterSignInUrl","__afterSignUpUrl","__signInForceRedirectUrl","__signUpForceRedirectUrl","__signInFallbackRedirectUrl","__signUpFallbackRedirectUrl","__clerk_debug",{"_41":24,"_23":24,"_42":28,"_43":44,"_45":28,"_46":26,"_47":24,"_48":28},"isSignedIn","proxyUrl","reason","session-token-and-uat-missing","message","publishableKey","isSatellite","domain","__clerkJSUrl","__clerkJSVersion","__telemetryDisabled","__telemetryDebug","routes/_index",{"_55":56,"_1002":1003},"questions",[57,195,231,255,280,309,338,363,388,416,445,474,499,528,553,578,602,627,651,676,701,725,761,785,809,833,857,881,905,929,954,978],{"_58":59,"_60":61,"_62":63,"_64":65,"_66":67,"_68":69,"_70":71,"_72":73,"_74":75,"_76":77,"_78":79,"_111":112,"_131":132,"_133":24,"_134":-5,"_135":136,"_137":138,"_159":152,"_153":160,"_155":160,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":165,"_169":170,"_175":176,"_177":178,"_189":190,"_191":-5,"_192":-5,"_193":194},"url","https://api.github.com/repos/pro-collection/interview-question/issues/546","repository_url","https://api.github.com/repos/pro-collection/interview-question","labels_url","https://api.github.com/repos/pro-collection/interview-question/issues/546/labels{/name}","comments_url","https://api.github.com/repos/pro-collection/interview-question/issues/546/comments","events_url","https://api.github.com/repos/pro-collection/interview-question/issues/546/events","html_url","https://github.com/pro-collection/interview-question/issues/546","id",1878562376,"node_id","I_kwDOJGDC6c5v-JZI","number",546,"title","如何理解前端工程化？","user",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"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",[113,124],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},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 项目工程化",{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},5312231007,"LA_kwDOJGDC6c8AAAABPKI2Xw","https://api.github.com/repos/pro-collection/interview-question/labels/%E9%98%BF%E9%87%8C%E5%B7%B4%E5%B7%B4","阿里巴巴","ededed","公司标签","state","open","locked","assignee","assignees",[],"milestone",{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":148,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-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",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"open_issues",454,"closed_issues",0,"created_at","2023-03-06T15:00:27Z","updated_at","2025-09-07T06:21:17Z","due_on","closed_at","comments","2023-09-02T10:03:59Z","author_association","MEMBER","active_lock_reason","sub_issues_summary",{"_166":152,"_167":152,"_168":152},"total","completed","percent_completed","issue_dependencies_summary",{"_171":152,"_172":152,"_173":152,"_174":152},"blocked_by","total_blocked_by","blocking","total_blocking","body","前端工程化是指将前端开发过程中的各种工具、技术和流程进行规范化和自动化，以提高前端开发效率、代码质量和团队协作能力的一种方法。前端工程化主要涵盖以下几个方面：\n\n1. 代码管理：使用版本控制系统（如Git）对前端项目进行代码管理，实现代码的版本控制、协作开发和代码回滚等功能。\n\n2. 代码规范：制定和遵循统一的前端代码规范，包括缩进、命名、注释等，以提高代码的可读性和可维护性。\n\n3. 模块化开发：使用模块化的开发方式，将前端代码拆分为独立的模块，以便于复用和维护。\n\n4. 构建工具：使用构建工具（如Webpack、Gulp）对前端代码进行构建、打包、压缩和优化等处理，提高开发效率和应用性能。\n\n5. 自动化测试：编写自动化测试用例，使用测试工具（如Jest、Mocha）进行自动化测试，以确保代码质量和功能的稳定性。\n\n6. 持续集成和部署：使用持续集成工具（如Jenkins、Travis CI）将代码自动构建、测试和部署到服务器，加快代码交付速度和减少人工操作。\n\n7. 性能优化：使用性能优化工具（如Webpack、Lighthouse）来分析和改进前端应用程序的性能，包括文件加载、资源压缩、缓存策略等方面。\n\n8. 文档和知识管理：编写和维护开发文档、API 文档以及团队知识库，方便团队成员之间的沟通和知识分享。\n\n通过前端工程化的实践，可以减少重复劳动、提高代码质量、加速开发流程和降低维护成本，从而更好地满足项目需求和提升用户体验。\n","reactions",{"_58":179,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/546/reactions","total_count","+1","-1","laugh","hooray","confused","heart","rocket","eyes","timeline_url","https://api.github.com/repos/pro-collection/interview-question/issues/546/timeline","performed_via_github_app","state_reason","score",1,{"_58":196,"_60":61,"_62":197,"_64":198,"_66":199,"_68":200,"_70":201,"_72":202,"_74":203,"_76":204,"_78":205,"_111":206,"_131":132,"_133":24,"_134":-5,"_135":209,"_137":210,"_159":194,"_153":223,"_155":224,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":225,"_169":226,"_175":227,"_177":228,"_189":230,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/545","https://api.github.com/repos/pro-collection/interview-question/issues/545/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/545/comments","https://api.github.com/repos/pro-collection/interview-question/issues/545/events","https://github.com/pro-collection/interview-question/issues/545",1878558373,"I_kwDOJGDC6c5v-Ial",545,"如何理解前端架构？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[207,208],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":211,"_68":212,"_62":213,"_70":214,"_72":215,"_74":216,"_76":217,"_122":218,"_147":219,"_149":220,"_151":152,"_131":132,"_153":221,"_155":222,"_157":-5,"_158":-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,"资深","资深级别面试问题",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},50,"2023-03-06T15:00:45Z","2025-07-06T12:02:25Z","2023-09-02T10:00:52Z","2025-11-04T04:13:18Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"前端架构是指在开发前端应用程序时，为了提高开发效率、代码可维护性和可扩展性，将前端代码组织和设计的一种架构体系。它涵盖了前端项目的整体结构、代码组织方式、技术选型、模块化开发、数据管理、状态管理、网络请求、路由管理等方面的规划和设计。\n\n前端架构的目标是使前端开发更加规范、高效和可持续。良好的前端架构可以帮助团队成员更好地协作、降低维护成本、提高开发效率、减少代码冗余和bug等。\n\n以下是一些常见的前端架构概念和思想：\n\n1. 分层架构：将前端应用程序划分为不同的层次，如视图层、业务逻辑层、数据层等，以实现各个层次的解耦和职责清晰。\n\n2. 组件化开发：将界面拆分为独立的可复用组件，通过组合不同的组件来构建页面，提高代码的可维护性和可复用性。\n\n3. 模块化开发：将代码按照功能或业务模块进行拆分，每个模块都有独立的职责和功能，便于团队协作和代码维护。\n\n4. 数据管理和状态管理：使用状态管理库（如Redux、Vuex）来管理应用程序的状态和数据流，使得数据的变化和传递更加可控和可预测。\n\n5. 路由管理：使用路由库（如React Router、Vue Router）来管理前端路由，实现页面之间的跳转和导航。\n\n6. 统一风格和规范：制定和遵循统一的编码规范、命名规范、目录结构等，以便于不同开发者之间的协作和代码的统一性。\n\n7. 自动化构建和部署：使用构建工具（如Webpack、Rollup）和自动化部署工具（如Jenkins、Travis CI）来提高开发效率和代码交付速度。\n\n8. 性能优化和项目优化：通过代码分割、懒加载、缓存、CDN 加速、前端性能监控等手段，提升应用程序的性能和用户体验。\n\n前端架构是一种组织和规划前端代码的方法论，旨在提高前端开发的效率和质量，同时也要根据具体项目的需求和规模来选择和适配合适的架构方案。\n",{"_58":229,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/545/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/545/timeline",{"_58":232,"_60":61,"_62":233,"_64":234,"_66":235,"_68":236,"_70":237,"_72":238,"_74":239,"_76":240,"_78":241,"_111":242,"_131":132,"_133":24,"_134":-5,"_135":244,"_137":245,"_159":152,"_153":247,"_155":248,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":249,"_169":250,"_175":251,"_177":252,"_189":254,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/543","https://api.github.com/repos/pro-collection/interview-question/issues/543/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/543/comments","https://api.github.com/repos/pro-collection/interview-question/issues/543/events","https://github.com/pro-collection/interview-question/issues/543",1878487808,"I_kwDOJGDC6c5v93MA",543,"前端基建设计到哪些方面【热度: 782】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[243],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":211,"_68":212,"_62":213,"_70":214,"_72":215,"_74":216,"_76":217,"_122":218,"_147":246,"_149":220,"_151":152,"_131":132,"_153":221,"_155":222,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-09-02T08:35:05Z","2023-09-02T08:35:14Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：前端工程化建设、前端基建\n\n前端基建是指在前端开发过程中，为提高开发效率、代码质量和团队协作而构建的一些基础设施和工具。下面是前端基建可以做的一些事情：\n\n1. `脚手架工具`\n\n开发和维护一个通用的脚手架工具，可以帮助团队快速初始化项目结构、配置构建工具、集成常用的开发依赖等。\n\n2. `组件库`\n\n开发和维护一个内部的组件库，包含常用的UI组件、业务组件等，提供给团队成员复用，减少重复开发的工作量。\n\n3. `构建工具和打包工具`\n\n搭建和维护一套完善的构建和打包工具链，包括使用Webpack、Parcel等工具进行代码的压缩、合并、打包等工具，优化前端资源加载和性能。\n\n4. `自动化测试工具`\n\n引入自动化测试工具，如Jest、Mocha等，编写和维护测试用例，进行单元测试、集成测试、UI测试等，提高代码质量和可靠性。\n\n5. `文档工具`\n\n使用工具如JSDoc、Swagger等，生成项目的API文档、接口文档等，方便团队成员查阅和维护。\n\n6. `Git工作流`\n\n制定和规范团队的Git工作流程，使用版本控制工具管理代码，方便团队协作和代码回退。\n\n7. `性能监控和优化`\n\n引入性能监控工具，如Lighthouse、Web Vitals等，对项目进行性能分析，优化网页加载速度、响应时间等。\n\n8. `工程化规范`\n\n制定并推广团队的代码规范、目录结构规范等，提高代码的可读性、可维护性和可扩展性。\n\n9. `持续集成和部署`\n\n搭建持续集成和部署系统，如Jenkins、Travis CI等，实现代码的自动构建、测试和部署，提高开发效率和代码质量。\n\n10. `项目文档和知识库`\n\n建立一个内部的项目文档和知识库，记录项目的技术细节、开发经验、常见问题等，方便团队成员查阅和学习。\n\n\n11. `代码质量工具`\n\n引入代码质量工具，如ESLint、Prettier等，对代码进行静态分析和格式化，提高代码的一致性和可读性。\n\n12. `国际化支持`\n\n为项目添加国际化支持，可以通过引入国际化库，如i18next、vue-i18n等，实现多语言的切换和管理。\n\n13. `错误监控和日志收集`\n\n引入错误监控工具，如Sentry、Bugsnag等，实时监控前端错误，并收集错误日志，方便进行问题排查和修复。\n\n14. `前端性能优化工具`\n\n使用工具如WebPageTest、Chrome DevTools等，对项目进行性能分析和优化，提高页面加载速度、响应时间等。\n\n15. `缓存管理`\n\n考虑合理利用浏览器缓存和服务端缓存，减少网络请求，提升用户访问速度和体验。\n\n16. `移动端适配`\n\n针对移动端设备，采用响应式设计或使用CSS媒体查询等技术，实现移动端适配，保证页面在不同尺寸的设备上有良好的显示效果。\n\n17. `安全防护`\n\n对项目进行安全审计，使用安全防护工具，如CSP（Content Security Policy）、XSS过滤等，保护网站免受常见的安全攻击。\n\n18. `性能优化指标监控`\n\n监控和分析关键的性能指标，如页面加载时间、首次渲染时间、交互响应时间等，以便及时发现和解决性能问题。\n\n19. `前端日志分析`\n\n使用日志分析工具，如ELK（Elasticsearch、Logstash、Kibana）等，对前端日志进行收集和分析，了解用户行为和页面异常情况。\n\n20. `跨平台开发`\n\n考虑使用跨平台开发框架，如React Native、Flutter等，实现一套代码在多个平台上复用，提高开发效率。\n\n21. `编辑器配置和插件`\n\n为团队提供统一的编辑器配置文件，包括代码格式化、语法高亮、代码自动补全等，并推荐常用的编辑器插件，提高开发效率。\n\n22. `文档生成工具`\n\n使用工具如Docusaurus、VuePress等，为项目生成漂亮的文档网站，方便团队成员查阅和维护项目文档。\n\n23. `Mock数据和接口管理`\n\n搭建一个Mock服务器，用于模拟后端接口数据，方便前端开发和测试，同时可以考虑使用接口管理工具，如Swagger等，方便接口的定义和调试。\n\n24. `前端监控和统计`\n\n引入前端监控工具，如Google Analytics、百度统计等，收集用户访问数据和行为信息，用于分析和优化用户体验。\n\n25. `移动端调试工具`\n\n使用工具如Eruda、VConsole等，帮助在移动端设备上进行调试和错误排查，提高开发效率。\n\n26. `自动化部署`\n\n配置自动化部署流程，将项目的代码自动部署到服务器或云平台，减少人工操作，提高发布效率和稳定性。\n\n27. `前端团队协作工具`\n\n使用团队协作工具，如GitLab、Bitbucket等，提供代码托管、项目管理、任务分配和团队沟通等功能，增强团队协作效率。\n\n28. `前端培训和知识分享`\n\n组织定期的前端培训和技术分享会，让团队成员相互学习和交流，推动技术的共享和提升。\n\n29. `客户端性能优化`\n\n针对移动端应用，可以使用工具如React Native Performance、Weex等，进行客户端性能优化，提高应用的响应速度和流畅度。\n\n30. `技术选型和评估`\n\n定期评估和研究前端技术的发展趋势，选择适用的技术栈和框架，以保持项目的竞争力和可持续发展。\n\n31. `统一的状态管理`\n\n引入状态管理工具，如Redux、Vuex等，帮助团队管理前端应用的状态，提高代码的可维护性和可扩展性。\n\n32. `前端日志记录`\n\n引入前端日志记录工具，如log4javascript、logrocket等，记录前端应用的运行日志，方便排查和解决问题。\n\n33. `前端代码扫描`\n\n使用静态代码扫描工具，如SonarQube、CodeClimate等，对前端代码进行扫描和分析，发现潜在的问题和漏洞。\n\n34. `前端数据可视化`\n\n使用数据可视化工具，如ECharts、Chart.js等，将数据以图表或图形的形式展示，增强数据的可理解性和可视化效果。\n\n35. `前端容灾和故障处理`\n\n制定容灾方案和故障处理流程，对前端应用进行监控和预警，及时处理和恢复故障，提高系统的可靠性和稳定性。\n\n36. `前端安全加固`\n\n对前端应用进行安全加固，如防止XSS攻击、CSRF攻击、数据加密等，保护用户数据的安全性和隐私。\n\n37. `前端版本管理`\n\n建立前端代码的版本管理机制，使用工具如Git、SVN等，管理和追踪代码的变更，方便团队成员之间的协作和版本控制。\n\n38. `前端数据缓存`\n\n考虑使用Local Storage、Session Storage等技术，对一些频繁使用的数据进行缓存，提高应用的性能和用户体验。\n\n39. `前端代码分割`\n\n使用代码分割技术，如Webpack的动态导入（Dynamic Import），将代码按需加载，减少初始加载的资源大小，提高页面加载速度。\n\n40. `前端性能监测工具`\n\n使用性能监测工具，如WebPageTest、GTmetrix等，监测前端应用的性能指标，如页面加载时间、资源加载时间等，进行性能优化。\n\n\n\n**参考文档**\n- [前端基建原来可以做这么多事情](https://juejin.cn/post/7256879435339628604)\n",{"_58":253,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/543/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/543/timeline",{"_58":256,"_60":61,"_62":257,"_64":258,"_66":259,"_68":260,"_70":261,"_72":262,"_74":263,"_76":264,"_78":265,"_111":266,"_131":132,"_133":24,"_134":-5,"_135":269,"_137":270,"_159":152,"_153":272,"_155":273,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":274,"_169":275,"_175":276,"_177":277,"_189":279,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/523","https://api.github.com/repos/pro-collection/interview-question/issues/523/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/523/comments","https://api.github.com/repos/pro-collection/interview-question/issues/523/events","https://github.com/pro-collection/interview-question/issues/523",1858158524,"I_kwDOJGDC6c5uwT-8",523,"webpack tree-shaking 在什么情况下会失效？【热度: 171】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[267,268],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":271,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-08-20T15:14:19Z","2023-11-01T15:46:48Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：tree shaking 失效\r\n\r\n在以下情况下，`webpack` 的 `tree-shaking` 可能会失效：\r\n\r\n1. 使用了 `sideEffects` 属性：在 webpack 的配置文件中，如果设置了 `sideEffects: true`，则 webpack 会假设所有模块都有副作用，因此不会进行 tree-shaking。这通常用于避免某些模块被误标记为无用代码而被删除。\r\n\r\n2. 动态导入：如果你使用了动态导入（例如使用了 `import()` 或 `require.ensure()`），webpack 无法静态分析模块的导入和导出，因此无法进行 tree-shaking。\r\n\r\n3. 使用了 `commonjs` 模块语法：如果你的代码中使用了 `commonjs` 模块语法（例如使用了 `require()` 或 `module.exports`），webpack 无法进行静态分析，因此无法进行 tree-shaking。\r\n\r\n4. 未使用 ES6 模块语法：tree-shaking 只能对 ES6 模块语法进行优化，如果你的代码中没有使用 ES6 模块语法，webpack 将无法进行 tree-shaking。\r\n\r\n5. 模块被动态引用或条件引用：如果模块的引用方式是动态的（例如在循环或条件语句中引用），或者通过字符串拼接来引用模块，webpack 无法确定哪些模块会被引用，因此无法进行 tree-shaking。\r\n\r\n6. 使用了副作用的代码：如果你的代码中包含有副作用的代码（例如在模块的顶级作用域中执行了一些操作），webpack 无法确定哪些代码是无用的，因此无法进行 tree-shaking。\r\n\r\n需要注意的是，即使 tree-shaking 可能会失效，webpack 仍然会进行其他优化，例如代码压缩和代码分割等。同时，你可以通过设置 `mode` 为 `production`，来启用 webpack 的优化功能，包括 tree-shaking。\r\n",{"_58":278,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/523/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/523/timeline",{"_58":281,"_60":61,"_62":282,"_64":283,"_66":284,"_68":285,"_70":286,"_72":287,"_74":288,"_76":289,"_78":290,"_111":291,"_131":132,"_133":24,"_134":-5,"_135":298,"_137":299,"_159":152,"_153":301,"_155":302,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":303,"_169":304,"_175":305,"_177":306,"_189":308,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/522","https://api.github.com/repos/pro-collection/interview-question/issues/522/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/522/comments","https://api.github.com/repos/pro-collection/interview-question/issues/522/events","https://github.com/pro-collection/interview-question/issues/522",1858154803,"I_kwDOJGDC6c5uwTEz",522,"前端模块化的演进过程【热度: 798】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[292,293],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":294,"_72":295,"_58":296,"_117":297,"_119":129,"_121":24,"_122":130},5316900032,"LA_kwDOJGDC6c8AAAABPOl0wA","https://api.github.com/repos/pro-collection/interview-question/labels/%E4%BA%AC%E4%B8%9C","京东",[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":300,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-08-20T15:03:38Z","2023-08-20T15:04:19Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：前端模块化演进\n\n### 1 函数作为块\n\n最开始的时候，是以函数为块来编程，因为函数有自己的作用域，相对比较独立\n\n```js\nfunction add(a,b){ \n // ...\n}\nfunction add1(a,b,c){\n // ...\n}\n```\n\n这种形式中，add和add1都是定义在全局作用域中的，会造成很多问题：\n\n1. 污染全局作用域，容易造成命名冲突\n2. 定义在全局作用域，数据不安全\n\n### 2 namespace模式\n\n使用对象作为独立块编程\n\n```js\nvar myModule={\n a:1,\n b:2,\n add:function(m,n){...}\n}\n```\n\n优点：减少了全局变量，有效解决了命名冲突\n\n缺点：\n\n1. 没有私有变量，使用起来很繁琐\n2. 数据不安全，模块外面可以随意修改内部的数据\n\n### 3 IIFE模式\n\n**使用立即执行函数来创建块，可以形成独立的作用域，外面无法访问，借助window对象来向外暴露接口**\n\n```js\n(function($){\n var a=1;\n var b=2;\n function add(m,n){\n ...\n }\n $('#id').addClass('.hehe');\n window.myModule={\n a:a,\n b:b,\n add:add\n }\n})()\n```\n\n优点：\n\n1. 减少了全局变量，解决了命名冲突\n2. 创建了独立的作用域，外部无法轻易修改内部数据\n\n缺点：\n\n**如果多个模块分布在多个js文件中，那么在html文件中就需要引入多个js文件**\n\n1. 会增加多个http请求，增加首屏的时候，降低用户体验\n2. **模块之间的引用关系很不明显，难以维护**\n\n\n### 4 CommonJS\n\n最开始出现的模块化方案是在node.js中实现的。node中的模块化方案是根据CommonJS规范实现的。\n\n**CommonJS规定每个文件就是一个模块，以同步的方式引入其他模块**\n\n```js\n//a.js\nfunction add(m,n){\n return m+n;\n}\nmodule.exports={add:add}\n\n\n//b.js\nconst {add} = require('./a.js');\nconsole.log(add(1,2)); // 3\n```\n\n这种方式是node端独有的，浏览器端如果想要使用，需要使用 **Browserify** 工具来解析。\n\n\n\n### 5 AMD和Require.js\n\nCommonJS模块之前是同步引入的，这在服务端是没有什么问题的，因为**文件都是保存在硬盘中，读取文件的速度是非常快的，同步加载带来的阻塞基本可以忽略不计。**\n\n但是如果在浏览器中使用CommonJS的话，因为**js文件是存在服务端需要请求获取，所以同步的方式加载会极大的阻塞页面**，显然是不可取的。\n\n于是诞生了AMD（Asynchronous Module Definition）规范，**一种异步加载的模块方案，使用回调函数来实现**。require.js实现了AMD的规范。\n\n```js\n//定义没有依赖的模块\n//a.js\ndefine(function(){\n function add(m,n){\n return m+n;\n }\n return {add:add}\n})\n\n//定义有依赖的模块\n//b.js\ndefine(['a'], function(a){\n const sum = a.add(1,2);\n return {sum:sum}\n})\n\n//引用模块\nrequire(['b'],function(b){\n console.log(b.sum); //3\n})\n```\n\n由上面代码分析Require.js的特点\n\n1. 依赖模块的代码都是放在回调函数中，等待模块都加载完成才执行这个回调函数，执行顺序可以保证\n2. **内部加载其他模块的时候，使用的是动态添加script标签的方式来实现动态加载**\n3. 内部需要缓存模块暴露出来的接口，避免多次执行\n\n**AMD推崇的是依赖前置，提前执行。**\n\n从上面代码可以看出，**在声明一个模块的时候，会在第一时间就将其依赖模块的内部代码执行完毕。而不是在真正使用的地方再去执行。**因此会带来一些资源浪费\n\n```js\ndefine(['a','b'],function(a,b){\n let sum = a.add(1,2);\n if(false){\n sum = b.add(1,2); //b模块是没有被使用的，应该是不需要执行模块内部代码的\n }\n return sum;\n})\n```\n\n\n\n### 6 CMD和Sea.js\n\n由于require.js自身的一些问题存在，所以后来在国内（玉伯）诞生了CMD（Common Module Definition）和Sea.js。\n\nCMD结合了CommonJS和AMD的特点，也是一种**异步**模块的方案，**提倡就近依赖，延迟执行。**\n\n**需要用到某个模块的时候，才用require引入，模块内部的代码也是在被引入的时候才会执行，声明的时候并没有执行。**\n\n语法设计上比较像CommonJS\n\n```js\n//定义模块 math.js\ndefine(function(require,exports,module){\n var a = require('./a.js'); // 引入模块\n function add(m,n){\n return m+n;\n }\n module.exports={\n add:add\n }\n});\n\n//加载模块\nseajs.use(['math.js'],function(math){\n var sum = math.add(1,2);\n})\n```\n\n看上面的代码可能会有疑问，模块是异步加载的，但是使用的时候require是同步使用的，没有回调函数，如何能够保证执行的顺序呢？这就不得不提sea.js中的静态依赖分析机制了。\n\n#### 6.1 Sea.js中的静态依赖分析机制\n\nSea.js中**模块加载的入口方法是use()方法，执行这个方法会开始加载所有的依赖模块**。然后sea.js中是就近依赖的，它是如何获取依赖模块的呢？\n\n**在define的方法中，如果传入的参数factory是一个函数，内部会执行函数的toString方法，转化成字符串，然后通过正则表达式分析字符串，获取require方法中的参数，通过路径分析去加载依赖的模块**。以此链式分析下去，边分析边加载模块，等待所有的依赖都加载完成之后，才开始调用use的回调函数，正式执行模块内代码。\n\n所以在require方法执行之前，对应的模块已经加载完成了，所以可以直接传入参数，执行模块函数体。\n\n#### 6.2 Sea.js的特点\n\n1. **就近依赖，延时执行**\n2. 内部拥有静态依赖分析机制，保证require之前，模块已经加载完毕，但是函数还没有执行\n3. 也是一种异步的模块化方案\n4. 内部也有缓存机制，缓存模块暴露的接口\n5. 内部加载模块的时候，和require.js一样，也是通过**动态增加script标签**来完成的\n\n\n\n### 7 ES Module\n\nES6开始，在语法标准上实现了模块化功能。简称ES Module\n\n**ES Module是一种静态依赖的模块化方案，模块与模块之间的依赖关系是在编译期完成连接的。**\n\n**前面所说的三种方案都是动态模块化方案，依赖模块都是动态引入的，而且模块都是一个对象。而ES Module中，模块不是一个对象，模块与模块之间也不是动态引入的，而且编译期间静态引入的，所以无法实现条件加载**\n\n```js\n//a.js\nfunction add(m,n){\n return m+n;\n}\nexport {add};\n\n// b.js\nimport {add} from './a.js';\nconsole.log(add(1,2)); //3\n```\n\n\n**参考文档**\n- [https://github.com/careyke/frontend_knowledge_structure/blob/master/javascript/module/question01_module.md](https://github.com/careyke/frontend_knowledge_structure/blob/master/javascript/module/question01_module.md)\n",{"_58":307,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/522/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/522/timeline",{"_58":310,"_60":61,"_62":311,"_64":312,"_66":313,"_68":314,"_70":315,"_72":316,"_74":317,"_76":318,"_78":319,"_111":320,"_131":132,"_133":24,"_134":-5,"_135":327,"_137":328,"_159":152,"_153":330,"_155":331,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":332,"_169":333,"_175":334,"_177":335,"_189":337,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/516","https://api.github.com/repos/pro-collection/interview-question/issues/516/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/516/comments","https://api.github.com/repos/pro-collection/interview-question/issues/516/events","https://github.com/pro-collection/interview-question/issues/516",1858088460,"I_kwDOJGDC6c5uwC4M",516,"[性能] 常见性能指标获取方式？【热度: 954】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[321,322],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":323,"_72":324,"_58":325,"_117":326,"_119":129,"_121":24,"_122":130},5342931240,"LA_kwDOJGDC6c8AAAABPnapKA","https://api.github.com/repos/pro-collection/interview-question/labels/%E7%BE%8E%E5%9B%A2","美团",[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":329,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-08-20T11:21:57Z","2023-08-20T11:22:19Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：web性能指标获取\n\n### 常见性能指标获取方式\n\n相关性能指标问题，可以看这个文章：[https://github.com/pro-collection/interview-question/issues/515](https://github.com/pro-collection/interview-question/issues/515)\n\n**指标所反映的用户体验**\n下表概述了我们的性能指标如何对应到我们的问题之上：\n\n**开始了吗？**\n\n- 首次绘制、首次内容绘制 First Paint (FP) / First Contentful Paint (FCP)\n\n**有用吗？**\n\n- 首次有效绘制、主要元素时间点 First Meaningful Paint (FMP) / Hero Element Timing\n\n**能用吗？**\n\n- 可交互时间点 Time to Interactive (TTI)\n\n**好用吗？**\n\n- 慢会话 Long Tasks (从技术上来讲应该是：没有慢会话)\n\n\n#### 页面何时开始渲染 - FP & FCP\n\n这两个指标，我们可以通过 performance.getEntry、performance.getEntriesByName、performanceObserver 来获取。\n\n```ts\nperformance.getEntries().filter(item => item.name === 'first-paint')[0]; // 获取 FP 时间\n\nperformance.getEntries().filter(item => item.name === 'first-contentful-paint')[0]; // 获取 FCP 时间\n\nperformance.getEntriesByName('first-paint'); // 获取 FP 时间\n\nperformance.getEntriesByName('first-contentful-paint'); // 获取 FCP 时间\n\n// 也可以通过 performanceObserver 的方式获取\nvar observer = new PerformanceObserver(function(list, obj) {\n var entries = list.getEntries();\n entries.forEach(item => {\n if (item.name === 'first-paint') {\n ...\n }\n if (item.name === 'first-contentful-paint') {\n ...\n }\n })\n});\nobserver.observe({type: 'paint'});\n```\n\n#### 页面何时渲染主要内容 - FMP & SI & LCP\n\n`FMP`, 是一个已经废弃的性能指标。在实践过程中，由于 FMP 对页面加载的微小差异过于敏感，经常会出现结果不一致的情况。此外，该指标的定义依赖于特定于浏览器的实现细节，这意味着它不能标准化，也不能在所有 Web 浏览器中实现。目前，官方并没有提供有效的获取 FMP 的接口，因此性能分析的时候不再使用这个指标。\n\n`SI` 和 FMP 一样，官方也没有提供有效的获取接口，只能通过 lighthouse 面板来查看，不作为 Sentry 等工具做性能分析的指标。\n\n`LCP`，和 FMP 类似，但只聚焦页面首次加载时最大元素的绘制时间点，计算相对简单一些。通过 performanceObserver 这个接口，我们可以获取到 LCP 指标数据。\n\n```ts\nnew PerformanceObserver((entryList) => {\n for (const entry of entryList.getEntries()) {\n console.log('LCP candidate:', entry.startTime, entry);\n }\n}).observe({type: 'largest-contentful-paint', buffered: true});\n```\n\n#### 何时可以交互 - TTI & TBT\n\n`TTI`, `time to ineractive`, 可交互时间， `lighthouse` 面板中的六大指标之一, 用于测量页面从开始加载到主要资源完成渲染，并能够快速、可靠地响应用户输入所需的时间, 值越小约好。 \n官方资料: [TTI](https://web.dev/i18n/zh/tti/) 。\n\n和 FMP、SI 一样，`官方并没有提供获取 TTI 的有效接口`，只能通过 lighthouse 面板来查看。\n\n**计算方式人如下**:\n\n1. 先进行 First Contentful Paint 首次内容绘制；\n\n2. 沿时间轴正向搜索时长至少为 5 秒的安静窗口，其中，安静窗口的定义为：没有长任务且不超过 2 个正在处理的网络请求;\n\n3. 沿时间轴反向搜索安静窗口之前的最后一个长任务，如果没有找到长任务，则在 FCP 步骤停止执行。\n\n4. TTI 是安静窗口之前最后一个长任务的结束时间（如果没有找到长任务，则与 FCP 值相同）。\n\n理解计算过程如下图：\n $\"image\"$ \n\nTTI 表示的是完全可交互的时间，每个 web 系统，对 TTI 时间定义可能并不一定相同，上面只是提供一个计算较为通用的 TTI 的一个方式。 \n\n#### 交互是否有延迟 - FID & MPFID & Long Task\n\n`FID 和 MPFID` 可用来衡量用户首次交互延迟的情况，`Long Task` 用来衡量用户在使用应用的过程中遇到的延迟、阻塞情况。\n\n**`FID`**，`first input delay`, 首次输入延迟，测量从用户第一次与页面交互（例如当他们单击链接、点按按钮或使用由 JavaScript 驱动的自定义控件）直到浏览器对交互作出响应，并实际能够开始处理事件处理程序所经过的时间。官方资料: FID。\nFID 指标的值越小约好。通过 performanceObserver，我们可以获取到 FID 指标数据。\n\n```ts\nnew PerformanceObserver((entryList) => {\n for (const entry of entryList.getEntries()) {\n const delay = entry.processingStart - entry.startTime;\n console.log('FID candidate:', delay, entry);\n }\n}).observe({type: 'first-input', buffered: true});\n```\n\n**`MPFID`**, `Max Potential First Input Delay`，最大潜在首次输入延迟，用于测量用户可能遇到的最坏情况的首次输入延迟。和 FMP 一样，这个指标已经被废弃不再使用。\n\n**`Long Task`**，衡量用户在使用过程中遇到的交互延迟、阻塞情况。这个指标，可以告诉我们哪些任务执行耗费了 50ms 或更多时间。\n\n```ts\nnew PerformanceObserver(function(list) {\n var perfEntries = list.getEntries();\n for (var i = 0; i < perfEntries.length; i++) {\n ...\n }\n}).observe({ type: 'longtask'});\n```\n\n#### 页面视觉是否有稳定 - CLS\n\n**`CLS`**, `Cumulative Layout Shift`, 累积布局偏移，用于测量整个页面生命周期内发生的所有意外布局偏移中最大一连串的布局偏移情况。官方资料: CLS。\n\nCLS, 值越小，表示页面视觉越稳定。通过 performanceObserver，我们可以获取到 CLS 指标数据。\n```ts\nnew PerformanceObserver(function(list) {\n var perfEntries = list.getEntries();\n for (var i = 0; i < perfEntries.length; i++) {\n ...\n }\n}).observe({type: 'layout-shift', buffered: true});\n```\n",{"_58":336,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/516/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/516/timeline",{"_58":339,"_60":61,"_62":340,"_64":341,"_66":342,"_68":343,"_70":344,"_72":345,"_74":346,"_76":347,"_78":348,"_111":349,"_131":132,"_133":24,"_134":-5,"_135":352,"_137":353,"_159":152,"_153":355,"_155":356,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":357,"_169":358,"_175":359,"_177":360,"_189":362,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/515","https://api.github.com/repos/pro-collection/interview-question/issues/515/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/515/comments","https://api.github.com/repos/pro-collection/interview-question/issues/515/events","https://github.com/pro-collection/interview-question/issues/515",1858046719,"I_kwDOJGDC6c5uv4r_",515,"[性能] 衡量页面性能的指标有哪些？【热度: 1,045】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[350,351],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":323,"_72":324,"_58":325,"_117":326,"_119":129,"_121":24,"_122":130},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":354,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-08-20T08:53:36Z","2023-08-20T08:53:37Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：web性能指标\n\n### 性能的核心问题\n\n- 什么样的性能指标最能度量人的感觉？\n- 怎样才能从我们的真实用户中获取这些指标？\n- 如何用我们所获取的指标来确定一个页面表现得是否「快」？\n- 当我们得知用户所感知的真实性能表现后，我们应该如何做才能避免重蹈覆辙，并在未来提高性能表现？\n\n### 以用户为中心的性能指标\n\n**开始了吗？**\n页面开始加载了吗？得到了服务端的回应吗？\n\n**有用吗？**\n有足够用户期望看到的内容被渲染出来了吗？\n\n**能用吗？**\n用户能够与我们的页面交互了吗？还是依然在加载？\n\n**好用吗？**\n交互是否流畅、自然、没有延迟与其他的干扰？\n\n#### 首次绘制（First Paint）和首次内容绘制（First Contentful Paint）\n\n首次绘制（FP）和首次内容绘制（FCP）。在浏览器导航并渲染出像素点后，这些指标点立即被标记。这些点对于用户而言十分重要，因为它回答了我们的第一个问题问题：**开始了吗**？\n\nFP与FCP的主要区别在于，FP标记浏览器所渲染的任何与导航前内容不同的点，而FCP所标记的是来自于DOM中的内容，可能是文本、图片、SVG，甚至是canvas元素。\n\n\n#### 首次有效绘制（First Meaningful Pain）和主要元素时间点（Hero Element Timing）\n\n首次有效绘制（FMP）回答了我们的问题：**有用吗**？对于现存的所有网页而言，我们不能去清晰地界定哪些元素的加载是「有用」的（因此目前尚无规范），\n但是对于开发者他们自己而言，他们很容易知道页面的哪些部分对于用户而言是最为有用的。\n\n![image](https://github.com/pro-collection/interview-question/assets/22188674/613b9446-c386-47c9-84fd-ce53e9e2f2b2)\n\n这些页面中「最重要的部分」通常被称为**主要元素**。举一些例子，在YouTube的播放页面，播放器就是主要元素。在Twitter中可能是通知的图标，或者是第一条推文。在天气应用中，主要元素应是指定位置的预测信息。在一个新闻站点中，它可能是摘要，或者是第一张插图。\n\n网页中总有一部分内容的重要性大于其余的部分。如果这部分的内容能够很快地被加载出来，用户甚至都不会在意其余部分的加载情况。\n\n\n#### 可交互时间（TTI）\n\n可交互时间（TTI）标记了你的页面已经呈现了画面，并且能够响应用户输入的时间点。页面不能响应用户输入有以下常见的原因：\n\n- 将被JavaScript所操作的元素还未被加载出来；\n- 一些慢会话阻塞了浏览器的主线程（如我们在上一部分所描述的）\n\nTTI所记录实际上是页面的JavaScript完成了初始化，主线程处于空闲的时间点。\n\n\n#### long tasks\n\n浏览器像是单线程的。某些情况下，一些任务将可能会花费很长的时间来执行，如果这种情况发生了，主线程阻塞，剩下的任务只能在队列中等待。\n\n用户所感知到的可能是输入的延迟，或者是哐当一下全部出现。这些是当今网页糟糕体验的主要来源。\n\nLong Tasks API认为任何超过50毫秒的任务都可能存在潜在的问题，并将这些任务揭露给开发者。既然能够满足50毫秒内完成任务，也就能够符合RAIL在100毫秒内相应用户输入的要求。\n\n\n#### 指标所反映的用户体验\n\n下表概述了我们的性能指标如何对应到我们的问题之上：\n\n**开始了吗**？\n- 首次绘制、首次内容绘制 First Paint (FP) / First Contentful Paint (FCP)\n\n**有用吗**？\n- 首次有效绘制、主要元素时间点 First Meaningful Paint (FMP) / Hero Element Timing\n\n**能用吗**？\n- 可交互时间点 Time to Interactive (TTI)\n\n**好用吗**？\n- 慢会话 Long Tasks (从技术上来讲应该是：没有慢会话)\n\n\n### 获取指标\n\n主要依赖浏览器提供的 api \n- [PerformanceObserver](https://developer.mozilla.org/zh-CN/docs/Web/API/PerformanceObserver)\n- [PerformanceEntry](https://developer.mozilla.org/zh-CN/docs/Web/API/PerformanceEntry)\n- [DOMHighResTimeStamp](https://developer.mozilla.org/zh-CN/docs/Web/API/DOMHighResTimeStamp)\n\n\n#### PerformanceObserver 使用示范\n\n要使用 PerformanceObserver，首先需要创建一个 PerformanceObserver 实例，并指定一个回调函数作为参数。回调函数将在性能事件触发时被调用。然后，通过 PerformanceObserver 的 observe() 方法去监听所关注的性能事件类型。\n\n以下是一个使用 PerformanceObserver 的示例代码：\n\n```javascript\n// 创建回调函数\nfunction performanceCallback(list, observer) {\n list.getEntries().forEach(entry => {\n console.log(entry.name + \"：\" + entry.startTime);\n });\n}\n\n// 创建 PerformanceObserver 实例\nconst observer = new PerformanceObserver(performanceCallback);\n\n// 监听性能事件类型\nobserver.observe({ entryTypes: [\"measure\", \"paint\"] });\n```\n\n在上面的代码中，定义了一个名为 `performanceCallback` 的回调函数，它接收两个参数：`list` 和 `observer`。`list` 参数是一个 PerformanceEntryList 对象，包含了所有触发的性能事件，可以通过 `getEntries()` 方法获取详细信息。`observer` 参数表示 PerformanceObserver 实例本身。\n\n然后，通过 `new PerformanceObserver(performanceCallback)` 创建了一个 PerformanceObserver 实例，并将 `performanceCallback` 作为回调函数传递进去。\n\n最后，通过 `observer.observe({ entryTypes: [\"measure\", \"paint\"] })` 方法，指定了要监听的性能事件类型，这里监听了 \"measure\" 和 \"paint\" 两种类型的事件。\n\n当指定的性能事件类型发生时，回调函数将被调用，并传递触发事件的 PerformanceEntry 对象作为参数。开发者可以在回调函数中进一步处理和分析这些对象，以获取性能数据并进行优化。\n\n需要注意的是，观察者模式是异步的，因此回调函数可能不会立即执行。另外，一旦创建了 PerformanceObserver 实例，需要调用其 `disconnect()` 方法来停止监听性能事件，避免内存泄漏。\n\n以上是 PerformanceObserver 的基本用法，开发者可以根据实际需求和业务场景来灵活运用。\n\n\n### PerformanceObserver 如何统计FP、FCP\n\n要使用 PerformanceObserver 统计 FP（First Paint）和 FCP（First Contentful Paint），可以按照以下步骤进行：\n\n1. 创建 PerformanceObserver 实例，并指定一个回调函数作为参数。\n\n```javascript\nconst observer = new PerformanceObserver((list) => {\n const entries = list.getEntries();\n entries.forEach((entry) => {\n if (entry.name === 'first-paint') {\n console.log('FP:', entry.startTime);\n } else if (entry.name === 'first-contentful-paint') {\n console.log('FCP:', entry.startTime);\n }\n });\n});\n```\n\n2. 使用 PerformanceObserver 的 observe() 方法监听 'paint' 类型的性能事件。\n\n```javascript\nobserver.observe({ entryTypes: ['paint'] });\n```\n\n3. 在回调函数中，通过遍历 PerformanceEntryList 对象的 getEntries() 方法获取所有触发的性能事件，然后根据 entry.name 来判断是否是 FP 或 FCP。\n\n4. 如果是 FP，可以通过 entry.startTime 获取其开始的时间戳，进行相应的处理。同样，如果是 FCP，也可以通过 entry.startTime 获取其开始的时间戳。\n\n完整的示例代码如下：\n\n```javascript\nconst observer = new PerformanceObserver((list) => {\n const entries = list.getEntries();\n entries.forEach((entry) => {\n if (entry.name === 'first-paint') {\n console.log('FP:', entry.startTime);\n } else if (entry.name === 'first-contentful-paint') {\n console.log('FCP:', entry.startTime);\n }\n });\n});\n\nobserver.observe({ entryTypes: ['paint'] });\n```\n\n在上述代码中，创建了一个 PerformanceObserver 实例，并指定一个回调函数。在回调函数中，根据 entry.name 的值判断是否是 FP 或 FCP，并打印出对应的开始时间戳。然后通过调用 observer.observe() 方法监听 'paint' 类型的性能事件。\n\n通过以上步骤，就可以使用 PerformanceObserver 统计 FP 和 FCP，并对这些性能指标进行进一步的处理和分析。\n\n#### PerformanceObserver 如何统计 long tasks\n\n要使用 PerformanceObserver 统计长任务（Long Tasks），可以按照以下步骤进行：\n\n1. 创建 PerformanceObserver 实例，并指定一个回调函数作为参数。\n\n```javascript\nconst observer = new PerformanceObserver((list) => {\n const entries = list.getEntries();\n entries.forEach((entry) => {\n console.log('Long Task:', entry);\n });\n});\n```\n\n2. 使用 PerformanceObserver 的 observe() 方法监听 'longtask' 类型的性能事件。\n\n```javascript\nobserver.observe({ entryTypes: ['longtask'] });\n```\n\n3. 在回调函数中，通过遍历 PerformanceEntryList 对象的 getEntries() 方法获取所有触发的长任务事件。\n\n4. 可以通过遍历获得的长任务事件数据，并进行进一步的处理和分析。\n\n完整的示例代码如下：\n\n```javascript\nconst observer = new PerformanceObserver((list) => {\n const entries = list.getEntries();\n entries.forEach((entry) => {\n console.log('Long Task:', entry);\n });\n});\n\nobserver.observe({ entryTypes: ['longtask'] });\n```\n\n在上述代码中，创建了一个 PerformanceObserver 实例，并指定一个回调函数。在回调函数中，遍历 PerformanceEntryList 对象的 getEntries() 方法获取所有长任务事件，并打印出相关的长任务数据。\n\n通过以上步骤，就可以使用 PerformanceObserver 统计长任务，并对这些长任务进行进一步的处理和分析。\n\n### 补充：页面性能指标有哪些？\n\n以下是常见的页面性能指标，按照阶段顺序进行表述：\n\n| 阶段 | 指标名称 | 描述 |\n|------------------|--------------------------------|----------------------------------------------------------------------------------------------|\n| 导航阶段 | DNS 解析时间 | 浏览器解析域名并获取目标服务器IP地址所花费的时间 |\n| 导航阶段 | TCP 连接时间 | 浏览器与服务器建立 TCP 连接所花费的时间 |\n| 导航阶段 | SSL/TLS 握手时间 | 如果网站启用了 HTTPS，浏览器与服务器进行 SSL/TLS 握手所花费的时间 |\n| 导航阶段 | 请求时间 | 浏览器发送 HTTP 请求并等待服务器响应的时间 |\n| 导航阶段 | 首字节时间（TTFB） | 浏览器收到服务器响应的第一个字节所花费的时间 |\n| 渲染阶段 | DOM 解析时间 | 浏览器将 HTML 文档解析为 DOM 树的时间 |\n| 渲染阶段 | CSS 解析时间 | 浏览器将 CSS 样式表解析为 CSSOM 树的时间 |\n| 渲染阶段 | 首次渲染时间（FP） | 浏览器将 DOM 树和 CSSOM 树合并，开始绘制页面的时间 |\n| 渲染阶段 | 首次内容绘制时间（FCP） | 页面首次有可见内容被绘制的时间 |\n| 渲染阶段 | 首次有意义绘制时间（FMP） | 页面首次有有意义的内容被绘制的时间 |\n| 交互阶段 | 首次输入延迟时间（FID） | 用户首次与页面进行交互（点击按钮、输入框等）后，页面响应交互的时间 |\n| 交互阶段 | 首次可交互时间（TTI） | 页面变得完全可交互（用户可以进行大部分常规操作）所花费的时间 |\n| 交互阶段 | 页面完全加载时间（Page Load） | 页面所有资源（包括图片、CSS、JavaScript等）加载完成、渲染完毕并且可交互的时间 |\n| 用户体验阶段 | 页面响应时间 | 用户发起请求后，页面完成响应所花费的时间 |\n| 用户体验阶段 | 页面加载时间 | 用户打开页面到页面加载完成所花费的时间 |\n| 用户体验阶段 | 页面交互性能 | 页面响应用户交互（点击、滚动等）的流畅程度 |\n\n请注意，以上仅为常见的页面性能指标，并非所有指标都适用于每个网站。具体的指标选择取决于你的应用的特点和需求。\n",{"_58":361,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/515/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/515/timeline",{"_58":364,"_60":61,"_62":365,"_64":366,"_66":367,"_68":368,"_70":369,"_72":370,"_74":371,"_76":372,"_78":373,"_111":374,"_131":132,"_133":24,"_134":-5,"_135":377,"_137":378,"_159":152,"_153":380,"_155":381,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":382,"_169":383,"_175":384,"_177":385,"_189":387,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/502","https://api.github.com/repos/pro-collection/interview-question/issues/502/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/502/comments","https://api.github.com/repos/pro-collection/interview-question/issues/502/events","https://github.com/pro-collection/interview-question/issues/502",1826673077,"I_kwDOJGDC6c5s4NG1",502,"浏览器本身是不支持模块化的, webpack 是如何通过文件打包，让浏览器可以读取到前端各个模块的代码的？【热度: 1,153】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[375,376],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":323,"_72":324,"_58":325,"_117":326,"_119":129,"_121":24,"_122":130},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":379,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-07-28T15:53:47Z","2023-07-28T15:53:48Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：webpack模块化、浏览器模块化支持\n\n浏览器本身不支持模块化的特性，无法直接读取和执行模块化的代码。Webpack通过使用一种称为\"模块化打包\"的方式，将模块化的代码转换为浏览器可以执行的形式。\n\nWebpack使用了一个称为\"模块系统\"的机制，通过对模块的依赖关系进行分析，将所有依赖的模块打包为一个或多个包含所有依赖关系的文件。这些打包后的文件被称为“打包产物”或“bundle”。\n\n在打包过程中，Webpack会根据配置文件中的入口点（entry point）来确定应用程序的起始模块。然后，它将从该模块开始递归地解析所有的依赖关系，包括其他模块或文件。Webpack通过识别模块之间的依赖关系，将它们合并到一个或多个打包产物中。\n\nWebpack还会对打包产物进行一系列的优化，例如代码压缩、拆分和按需加载等，以提高应用程序的性能和加载速度。\n\n当浏览器加载打包产物时，它会执行其中包含的代码，并通过模块系统来解决模块之间的依赖关系。Webpack为浏览器提供了一个称为\"运行时\"的文件，它是Webpack打包产物的一部分，负责处理模块之间的依赖关系，并提供加载和执行模块的功能。\n\n通过Webpack的打包过程，浏览器可以读取和解析打包产物中的模块化代码，并顺利执行应用程序的逻辑。这样，开发者可以在编写代码时使用模块化的语法，而无需担心浏览器的兼容性问题。\n",{"_58":386,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/502/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/502/timeline",{"_58":389,"_60":61,"_62":390,"_64":391,"_66":392,"_68":393,"_70":394,"_72":395,"_74":396,"_76":397,"_78":398,"_111":399,"_131":132,"_133":24,"_134":-5,"_135":406,"_137":407,"_159":152,"_153":409,"_155":409,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":410,"_169":411,"_175":412,"_177":413,"_189":415,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/482","https://api.github.com/repos/pro-collection/interview-question/issues/482/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/482/comments","https://api.github.com/repos/pro-collection/interview-question/issues/482/events","https://github.com/pro-collection/interview-question/issues/482",1816981194,"I_kwDOJGDC6c5sTO7K",482,"如何搭建一套灰度系统？【热度: 1,226】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[400,401],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":402,"_72":403,"_58":404,"_117":405,"_119":129,"_121":24,"_122":130},5312726360,"LA_kwDOJGDC6c8AAAABPKnFWA","https://api.github.com/repos/pro-collection/interview-question/labels/%E8%85%BE%E8%AE%AF","腾讯",[],{"_58":211,"_68":212,"_62":213,"_70":214,"_72":215,"_74":216,"_76":217,"_122":218,"_147":408,"_149":220,"_151":152,"_131":132,"_153":221,"_155":222,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-07-23T04:18:11Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：灰度上线\n\n这个是一个非常复杂的话题，没法直接给出答案，进提供一些实现的思路：\n\n**什么是灰度**\n\n灰度系统可以把流量划分成多份，一份走新版本代码，一份走老版本代码。\n\n而且灰度系统支持设置流量的比例，比如可以把走新版本代码的流程设置为 5%，没啥问题再放到 10%，50%，最后放到 100% 全量。\n\n这样可以把出现问题的影响降到最低。\n\n而且灰度系统不止这一个用途，比如产品不确定某些改动是不是要的，就要做 AB 实验，也就是要把流量分成两份，一份走 A 版本代码，一份走 B 版本代码。\n\n\n**实现思路**\n\n1. 后端支持：灰度上线需要后端的支持，通过后端的灰度发布控制，可以将不同版本的前端应用分配给不同用户。\n\n2. 搭建网关层：支持一部分用户分发到 A 版本，一部分用户分发到 B 版本（通常使用 nginx 搭建）。\n \n3. 版本管控机制：使用版本控制系统（如Git、package.version、hash version 等）来管理不同版本的前端应用代码。在灰度上线时，可以根据需要切换到特定的版本。\n\n4. 动态路由：通过动态路由配置，将用户请求导向不同版本的前端应用。例如，可以使用Nginx或其他反向代理服务器来实现动态路由。\n\n5. 流量染色：使用Cookie或Session来控制用户的灰度版本访问。可以通过设置不同的Cookie值或Session标记，将用户分配到不同的灰度版本。\n\n6. 更复杂的漏量配置：例如要根据部门、权限、角色等方式来开放灰度；可以使用让用户访问应用的时候，查询其权限和角色，根据权限和角色来分发不同的页面路由。\n\n\n**参考文档**\n\n- [基于 Nginx 实现一个灰度上线系统](https://juejin.cn/post/7250914419579944997)\n",{"_58":414,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/482/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/482/timeline",{"_58":417,"_60":61,"_62":418,"_64":419,"_66":420,"_68":421,"_70":422,"_72":423,"_74":424,"_76":425,"_78":426,"_111":427,"_131":132,"_133":24,"_134":-5,"_135":434,"_137":435,"_159":152,"_153":437,"_155":438,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":439,"_169":440,"_175":441,"_177":442,"_189":444,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/467","https://api.github.com/repos/pro-collection/interview-question/issues/467/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/467/comments","https://api.github.com/repos/pro-collection/interview-question/issues/467/events","https://github.com/pro-collection/interview-question/issues/467",1775084768,"I_kwDOJGDC6c5pzaTg",467,"如何理解研发流程和研发效率，如何保障研发效率",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[428,429],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":430,"_72":431,"_58":432,"_117":433,"_119":129,"_121":24,"_122":130},5326133419,"LA_kwDOJGDC6c8AAAABPXZYqw","https://api.github.com/repos/pro-collection/interview-question/labels/%E5%B0%8F%E7%B1%B3","小米",[],{"_58":211,"_68":212,"_62":213,"_70":214,"_72":215,"_74":216,"_76":217,"_122":218,"_147":436,"_149":220,"_151":152,"_131":132,"_153":221,"_155":222,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-06-26T15:45:30Z","2023-06-26T15:45:31Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"### 保障研发效率\n\n研发流程指的是从需求调研、设计、开发、测试、发布、维护等一系列环节组成的整个研发过程。它是实现软件产品的必经之路，可以帮助团队规范化、标准化研发流程，提高研发效率、降低研发成本、提高产品质量和用户满意度。\n\n研发效率指的是在研发流程中，完成同样的工作所需要的时间和成本，也就是研发效率越高，就可以在同样的时间内完成更多的工作，并在更短的时间内推出产品，提高团队的竞争力和市场占有率。\n\n保障研发效率可以从以下几个方面入手：\n\n1. 优化研发流程：通过优化整个研发流程，缩短产品上线周期，降低研发成本，提高产品质量和用户满意度。\n\n2. 确定明确的目标和任务：团队需要清楚地了解产品的目标和任务，明确每个人的责任和任务，以便更好地完成工作。\n\n3. 提供优秀的工具和环境：为团队提供高效的工具和优秀的开发环境，帮助开发者更好地完成工作，提高工作效率。\n\n4. 加强团队协作和沟通：团队成员之间需要建立良好的沟通和协作机制，通过有效的沟通和协作，提高工作效率和质量。\n\n5. 持续学习和提高技能：团队成员需要不断学习新知识和提高技能，接受新技术，以便更好地完成工作，提高研发效率。\n\n\n#### 具体讲一下如何优化研发流程\n\n优化研发流程可以从以下几个方面入手：\n\n1. 需求管理：建立明确的需求管理机制，包括需求收集、需求筛选、需求优化、需求变更管理等，以确保需求的准确性、完整性、一致性和可追溯性。\n\n2. 设计管理：建立明确的设计管理机制，包括设计评审、设计文档管理、设计变更管理等，以确保设计的合理性、可行性、可维护性和可扩展性。\n\n3. 开发管理：建立高效的开发管理机制，包括任务分配、代码管理、代码审查、编码规范管理等，以确保开发的效率、质量和一致性。\n\n4. 测试管理：建立严格的测试管理机制，包括测试计划、测试用例管理、测试环境管理、缺陷管理等，以确保产品的质量和稳定性。\n\n5. 发布管理：建立有效的发布管理机制，包括版本控制、发布计划、发布测试、发布文档等，以确保产品的稳定性和用户满意度。\n\n6. 迭代管理：建立迭代管理机制，通过不断的迭代和优化，提高产品的质量和用户满意度，保持团队的创新和活力。\n\n7. 数据分析：建立数据分析机制，通过数据分析和用户反馈，不断优化产品和流程，提高团队的效率和竞争力。\n\n优化研发流程需要建立标准化、规范化的流程和管理机制，不断优化和改善流程，并建立有效的沟通和协作机制，以提高团队的效率和产品质量，满足用户的需求和期望。\n\n\n**如何保证上述机制能够正确推进下去？**\n\n为了确保上述机制能够正确推进下去，可以采取以下措施：\n\n1. 建立标准化的流程和管理机制，并将其纳入团队的日常工作流程中，确保每个团队成员都能够遵循。\n\n2. 建立监控和评估机制，对各项机制进行定期的检查、评估和反馈，并根据实际情况进行调整和改进。\n\n3. 建立协作和沟通机制，促进团队成员之间的协作和沟通，确保各项机制能够得到正确的执行和落实。\n\n4. 建立培训和学习机制，定期培训团队成员，提高其专业技能和管理能力，增强其执行机制的能力和信心。\n\n5. 采用项目管理工具和平台，对各项机制进行集中管理和监控，确保团队成员能够及时获取和共享必要的信息和资源。\n\n要保证各项机制能够正确推进下去，需要建立完善的流程和管理机制，并通过监控、评估、协作、沟通、培训和技术支持等措施，确保团队成员能够正确执行和落实机制，从而提高团队的效率和竞争力。\n\n\n#### 确定明确需求目标和需求内容\n\n首要任务是对需求进行拆解拆分，需要进行需求拆分来更好地管理和实现项目目标。以下是对大型项目进行需求拆分的建议：\n\n对于一个大型项目，需要进行需求拆分来更好地管理和实现项目目标。以下是对大型项目进行需求拆分的建议：\n\n1. 确定项目范围：明确项目的目标和范围，明确项目所需的主要功能和特性。\n\n2. 列出项目需求：将项目所需的各种需求列出来，包括功能需求、性能需求、安全需求、可靠性需求等。\n\n3. 进行需求分类：将需求进行分类，可以按照功能、用户、业务流程等方式进行分类。\n\n4. 制定需求文档：根据需求分类，制定详细的需求文档，包括需求描述、优先级和验收标准等。\n\n5. 制定项目计划：根据需求文档，制定项目计划，包括任务分解、时间安排和资源分配等。\n\n6. 协同开发：在开发过程中，需要协同进行开发，进行需求变更和调整。\n\n7. 进行验收和测试：在项目结束时，进行验收和测试，确保项目满足客户需求和要求。\n\n",{"_58":443,"_180":194,"_181":194,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/467/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/467/timeline",{"_58":446,"_60":61,"_62":447,"_64":448,"_66":449,"_68":450,"_70":451,"_72":452,"_74":453,"_76":454,"_78":455,"_111":456,"_131":132,"_133":24,"_134":-5,"_135":463,"_137":464,"_159":152,"_153":466,"_155":467,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":468,"_169":469,"_175":470,"_177":471,"_189":473,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/394","https://api.github.com/repos/pro-collection/interview-question/issues/394/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/394/comments","https://api.github.com/repos/pro-collection/interview-question/issues/394/events","https://github.com/pro-collection/interview-question/issues/394",1734491919,"I_kwDOJGDC6c5nYj8P",394,"[webpack] 提高 webpack 的构建速度的办法有哪些【热度: 1,208】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[457,458],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":459,"_72":460,"_58":461,"_117":462,"_119":129,"_121":24,"_122":130},5312214934,"LA_kwDOJGDC6c8AAAABPKH3lg","https://api.github.com/repos/pro-collection/interview-question/labels/%E7%BD%91%E6%98%93","网易",[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":465,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-05-31T15:30:28Z","2023-11-01T15:01:44Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：webpack 构建、webpack 构建优化、webpack 构建速度\n\n以下是一些可以提高Webpack构建速度的办法：\n\n1. 使用更快的构建工具：升级Webpack到最新版本，因为每个新版本通常都会带来性能改进和优化。\n \n2. 减少文件的数量：通过代码拆分和按需加载等技术，将代码拆分成更小的模块，减少每次构建需要处理的文件数量。\n \n3. 使用缓存：启用Webpack的缓存功能，可以在多次构建过程中复用已经构建好的模块，从而减少重新构建的时间。\n \n4. 使用多线程/多进程构建：通过使用工具如HappyPack或thread-loader等，可以将Webpack的构建过程并行化，利用多线程或多进程来加速构建速度。\n \n5. 优化Loader配置：确保Loader的配置尽可能精确，只对需要处理的文件进行操作，并且使用高效的Loader插件。避免不必要的文件处理和转换，以提高构建速度。\n\n6. 使用DLL和缓存组：使用Webpack的DLLPlugin和CacheGroups等功能，可以将一些稳定不变的依赖提前编译和缓存，减少每次构建的时间。\n\n7. 压缩输出文件：使用Webpack的压缩插件（如UglifyJsPlugin）对输出文件进行压缩和混淆，减小文件大小，加快加载速度。\n\n8. 配置resolve.extensions：通过配置Webpack的resolve.extensions，明确指定需要处理的文件类型，避免Webpack进行多余的文件扫描和匹配。\n\n9. 开启持久化缓存：使用Webpack的持久化缓存插件（如HardSourceWebpackPlugin），将构建过程中的中间结果缓存到硬盘中，提高后续构建的速度。\n\n10. 使用Tree Shaking：利用Webpack的Tree Shaking特性，移除未使用的代码，减小输出文件的体积，加快加载速度。\n\n这些是提高Webpack构建速度的一些常见方法，可以根据具体项目的需求和情况选择适合的优化策略。同时，不同的项目和环境可能会有不同的性能瓶颈，因此需要根据实际情况进行具体的优化和调整。\n\n",{"_58":472,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/394/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/394/timeline",{"_58":475,"_60":61,"_62":476,"_64":477,"_66":478,"_68":479,"_70":480,"_72":481,"_74":482,"_76":483,"_78":484,"_111":485,"_131":132,"_133":24,"_134":-5,"_135":488,"_137":489,"_159":152,"_153":491,"_155":492,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":493,"_169":494,"_175":495,"_177":496,"_189":498,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/390","https://api.github.com/repos/pro-collection/interview-question/issues/390/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/390/comments","https://api.github.com/repos/pro-collection/interview-question/issues/390/events","https://github.com/pro-collection/interview-question/issues/390",1732544456,"I_kwDOJGDC6c5nRIfI",390,"[Webpack] webpack5 Module Federation 了解多少",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[486,487],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":294,"_72":295,"_58":296,"_117":297,"_119":129,"_121":24,"_122":130},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":490,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-05-30T15:53:52Z","2023-11-01T15:07:35Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"### 概念\n\nWebpack 5 的 Module Federation 是一项功能强大的功能，它允许将 JavaScript 应用程序拆分成独立的模块，并在不同的 Webpack 构建中共享这些模块。它解决了多个独立应用程序之间共享代码的问题，使得实现微前端架构变得更加容易。\n\nModule Federation 可以将一个应用程序拆分成多个独立的子应用，每个子应用都可以被独立开发、部署和运行。每个子应用都可以通过配置指定需要共享的模块，然后将这些共享模块以动态方式加载到其他子应用中使用，而无需将这些模块打包进每个子应用的构建文件中。\n\nModule Federation 的核心概念是 \"容器\"（Container）和 \"远程\"（Remote）。容器是一个主应用程序，它可以加载和渲染其他子应用程序，而远程是一个独立的子应用程序，它提供了一些模块供其他子应用程序使用。\n\nModule Federation 提供了一种简单的方式来定义远程模块，并在容器中引用这些远程模块。容器可以从远程加载模块，并通过配置将这些模块暴露给其他子应用程序。这样，子应用程序可以通过远程加载和使用容器中的模块，实现了模块的共享和动态加载。\n\nModule Federation 在实现微前端架构时非常有用，可以将多个独立开发的子应用程序组合成一个整体，并实现共享模块和资源的灵活管理。它提供了一种解决方案，让多个团队可以独立开发和部署自己的子应用程序，同时又能够共享代码和资源，提高开发效率和整体性能。\n\nWebpack 5 的 Module Federation 是一项用于实现微前端架构的功能，它可以将 JavaScript 应用程序拆分成独立的子应用程序，并通过动态加载和共享模块的方式实现子应用程序之间的交互和共享。\n\n\n### 使用示范\n\n下面是一个简单的示例，演示如何在 Webpack 5 中使用 Module Federation。\n\n假设我们有两个独立的应用程序：App1 和 App2。我们将使用 Module Federation 将 App2 的模块共享给 App1。\n\n首先，我们需要在 App2 的 Webpack 配置中启用 Module Federation：\n\n```javascript\n// webpack.config.js (App2)\n\nconst { ModuleFederationPlugin } = require('webpack');\n\nmodule.exports = {\n // ...其他配置\n plugins: [\n new ModuleFederationPlugin({\n name: 'app2',\n filename: 'remoteEntry.js',\n exposes: {\n './Button': './src/Button', // 暴露 App2 的 Button 模块\n },\n }),\n ],\n};\n```\n\n接下来，我们需要在 App1 的 Webpack 配置中配置远程加载 App2 的模块：\n\n```javascript\n// webpack.config.js (App1)\n\nconst { ModuleFederationPlugin } = require('webpack');\n\nmodule.exports = {\n // ...其他配置\n plugins: [\n new ModuleFederationPlugin({\n name: 'app1',\n remotes: {\n app2: 'app2@http://localhost:3002/remoteEntry.js', // 远程加载 App2 的模块\n },\n }),\n ],\n};\n```\n\n在 App1 中，我们可以像使用本地模块一样使用 App2 的模块：\n\n```javascript\n// App1\n\nimport React from 'react';\nimport ReactDOM from 'react-dom';\nimport App2Button from 'app2/Button'; // 远程加载 App2 的 Button 模块\n\nReactDOM.render(, document.getElementById('root'));\n```\n\n在上面的示例中，我们通过 Module Federation 将 App2 的 Button 模块暴露给了 App1，然后在 App1 中可以直接通过 `import` 语句引入并使用。\n\n需要注意的是，App1 需要在 `remotes` 配置中指定远程加载的模块，其中 `app2` 是一个远程模块的名称，而 `http://localhost:3002/remoteEntry.js` 是 App2 构建输出的远程入口文件。\n\n这只是一个简单的示例，实际使用中可能涉及更复杂的配置和场景。但通过以上配置，我们可以实现在不同应用程序之间共享模块，并通过动态加载的方式使用远程模块。\n\n",{"_58":497,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/390/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/390/timeline",{"_58":500,"_60":61,"_62":501,"_64":502,"_66":503,"_68":504,"_70":505,"_72":506,"_74":507,"_76":508,"_78":509,"_111":510,"_131":132,"_133":24,"_134":-5,"_135":517,"_137":518,"_159":152,"_153":520,"_155":521,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":522,"_169":523,"_175":524,"_177":525,"_189":527,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/384","https://api.github.com/repos/pro-collection/interview-question/issues/384/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/384/comments","https://api.github.com/repos/pro-collection/interview-question/issues/384/events","https://github.com/pro-collection/interview-question/issues/384",1730948526,"I_kwDOJGDC6c5nLC2u",384,"source map 了解多少【热度: 396】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[511,512],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":513,"_72":514,"_58":515,"_117":516,"_119":129,"_121":24,"_122":130},5312738037,"LA_kwDOJGDC6c8AAAABPKny9Q","https://api.github.com/repos/pro-collection/interview-question/labels/%E7%99%BE%E5%BA%A6","百度",[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":519,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-05-29T15:28:19Z","2023-05-29T15:28:20Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：source map 原理\n\n### Source Map（源映射）作用\n\nSource Map（源映射）是一种文件，用于将压缩、混淆或编译后的代码映射回原始的源代码，以便在调试过程中能够直接查看和调试源代码。它提供了压缩文件和源文件之间的映射关系，包括每个压缩文件中的代码位置、原始文件的路径和行号等信息。\n\nSource Map的主要作用如下：\n\n1. 调试：在开发过程中，源代码经常会被压缩、合并或转换为其他形式的代码，这使得在调试时直接查看和调试源代码变得困难。Source Map提供了一种方式，通过将压缩代码映射回源代码，开发者可以在调试器中直接查看和调试原始的、易于理解的源代码。\n\n2. 错误追踪：当发生错误或异常时，浏览器或运行环境会提供错误信息，其中包含了压缩后的代码行号和列号。Source Map可以将这些行号和列号映射回源代码的行号和列号，帮助开发者定位和追踪错误。\n\n3. 性能分析：Source Map可以提供压缩文件中每个代码片段对应的原始文件位置信息，这对于性能分析工具来说非常有用。性能分析工具可以使用Source Map来将性能数据映射回源代码，以便更准确地分析和优化代码性能。\n\nSource Map的原理是通过在压缩文件中添加特定的注释或者生成独立的.map文件来存储映射关系。在调试过程中，浏览器或调试器会读取Source Map，并根据其中的映射关系将压缩代码中的行号、列号等信息映射回源代码的对应位置。\n\n### Source Map（源映射）实现原理\n\nSource Map 的实现原理可以简单描述如下：\n\n1. 生成 Source Map：在代码的压缩、混淆或编译过程中，生成器会创建一个 Source Map 对象，并收集相关的映射信息。这些信息包括原始文件路径、行号、列号以及对应的压缩文件中的位置信息。\n\n2. 生成编码字符串：将收集到的映射信息使用 VLQ（Variable Length Quantity）编码进行压缩，将数字转换为可变长度的 Base64 编码字符串。VLQ 编码能够通过特定的规则将数字转换为可变长度的字符串，以减小 Source Map 的体积。\n\n3. 关联 Source Map：在生成的压缩文件中，通过注释或独立的 .map 文件将 Source Map 关联到压缩文件。注释方式可以通过特定的注释语法将编码字符串直接嵌入到压缩文件中，而独立的 .map 文件则将编码字符串保存在一个独立的文件中。\n\n4. 调试时使用 Source Map：在调试过程中，当开发者需要查看或调试源代码时，浏览器或调试工具会加载关联的 Source Map 文件，根据映射关系将压缩文件中的位置信息映射回源代码的对应位置。\n\n通过这种方式，Source Map 实现了将压缩后的代码映射回原始源代码的功能，使得在调试、错误追踪和性能分析时能够更方便地操作和理解源代码。实际上，Source Map 的实现会有更多的细节和规范，但以上是其基本的实现原理概述。\n",{"_58":526,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/384/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/384/timeline",{"_58":529,"_60":61,"_62":530,"_64":531,"_66":532,"_68":533,"_70":534,"_72":535,"_74":536,"_76":537,"_78":538,"_111":539,"_131":132,"_133":24,"_134":-5,"_135":542,"_137":543,"_159":152,"_153":545,"_155":546,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":547,"_169":548,"_175":549,"_177":550,"_189":552,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/379","https://api.github.com/repos/pro-collection/interview-question/issues/379/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/379/comments","https://api.github.com/repos/pro-collection/interview-question/issues/379/events","https://github.com/pro-collection/interview-question/issues/379",1730878870,"I_kwDOJGDC6c5nKx2W",379,"如何定制前端项目代码规范【热度: 1,155】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[540,541],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":513,"_72":514,"_58":515,"_117":516,"_119":129,"_121":24,"_122":130},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":544,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-05-29T14:35:13Z","2023-05-29T14:35:14Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：定制前端代码规范\n\n当按照上述步骤定制前端代码规范时，可以按照以下详细步骤执行：\n\n1. 选择代码规范工具：\n\n * 研究可用的代码规范工具，如 ESLint、Prettier 等。\n * 比较各工具的功能、灵活性和社区支持，并选择最适合你团队和项目的工具。\n\n2. 定义规范：\n\n * 针对项目的需求和团队的编码风格，制定代码规范的具体规则和约定。\n * 参考行业内的代码规范，如 Airbnb JavaScript Style Guide、Google JavaScript Style Guide 等，以获取最佳实践和通用规则的参考。\n * 考虑以下方面进行规范定义：\n * 缩进和空格：确定使用的缩进大小、空格还是制表符等。\n * 命名约定：定义变量、函数、类、文件等的命名约定。\n * 代码风格：确定代码的风格规则，如花括号的位置、换行符的使用等。\n * 语法约定：定义应该使用的语言特性和语法约定，如使用严格模式、避免使用特定的语言功能等。\n\n3. 配置规范工具：\n\n * 创建代码规范工具的配置文件，如 `.eslintrc.js` 或 `.prettierrc`。\n * 在配置文件中指定所选规范工具的规则和选项，根据定义的规范进行配置。\n * 根据需要，可以启用或禁用不同的规则，并进行其他自定义配置。\n\n4. 集成到开发环境：\n\n * 集成代码规范工具到开发环境，以实现自动检测和修复代码规范问题。\n * 针对使用的编辑器或集成开发环境（IDE），安装相应的插件或扩展来支持代码规范检查和格式化。\n * 配置构建工具（如 webpack）或版本控制系统（如 Git）的钩子，以在代码提交前运行代码规范检查。\n\n5. 告知团队：\n\n * 与团队成员分享定制的代码规范，并解释规范的目的和重要性。\n * 提供规范的文档或指南，以便团队成员参考和遵循。\n * 组织一个会议或培训，介绍代码规范并解答团队成员的疑问。\n\n6. 定期审查和更新：\n\n * 定期审查代码规范的有效性，并根据实际需求进行更新和调整。\n * 接收团队成员的反馈和建议，以改进和优化代码规范。\n * 在项目演进和技术发展的过程中，适时地更新代码规范以适应变化的需求。\n\n以上步骤是一个通用的指南，你可以根据自己的团队和项目的特定要求进行调整和执行。此外，团队中的讨论和协商也是非常重要的，确保所有成员都参与到代码规范的制定和执行中。\n\n可以参考文档：https://juejin.cn/post/7085257325165936648\n",{"_58":551,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/379/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/379/timeline",{"_58":554,"_60":61,"_62":555,"_64":556,"_66":557,"_68":558,"_70":559,"_72":560,"_74":561,"_76":562,"_78":563,"_111":564,"_131":132,"_133":24,"_134":-5,"_135":567,"_137":568,"_159":152,"_153":570,"_155":571,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":572,"_169":573,"_175":574,"_177":575,"_189":577,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/377","https://api.github.com/repos/pro-collection/interview-question/issues/377/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/377/comments","https://api.github.com/repos/pro-collection/interview-question/issues/377/events","https://github.com/pro-collection/interview-question/issues/377",1730836821,"I_kwDOJGDC6c5nKnlV",377,"如何编写一个 babel 插件【热度: 1,062】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[565,566],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":459,"_72":460,"_58":461,"_117":462,"_119":129,"_121":24,"_122":130},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":569,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-05-29T14:12:18Z","2023-05-29T14:12:20Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：babel插件、babel插件api、babel插件代码示例\n\n### 编写一个 babel 插件的基本步骤\n\n编写一个 Babel 插件可以让你自定义转换、分析或操作 JavaScript 代码。下面是编写 Babel 插件的基本步骤：\n\n1. 安装 Babel：首先，确保你已经安装了 Babel 的相关工具和依赖。可以使用 npm 或 yarn 安装 `@babel/core`、`@babel/preset-env` 和 `@babel/plugin-syntax-plugin-name`。\n\n2. 创建插件文件：在项目中创建一个新的 JavaScript 文件，用于编写自定义插件的代码。命名约定是以 `babel-plugin-` 开头，例如 `babel-plugin-custom-plugin.js`。\n\n3. 导出插件函数：在插件文件中，导出一个函数作为你的插件。这个函数将接收一个 Babel 的 `babel` 对象作为参数，包含了一些 Babel 的工具方法，如 `types` 和 `template`。\n\n```javascript\nmodule.exports = function(babel) {\n // 插件代码\n};\n```\n\n4. 实现插件逻辑：在插件函数内部，实现你的插件逻辑。可以使用 `babel.types` 对象提供的方法来操作抽象语法树（AST）节点，例如 `babel.types.VariableDeclaration`、`babel.types.CallExpression` 等。\n\n```javascript\nmodule.exports = function(babel) {\n const { types: t } = babel;\n\n return {\n visitor: {\n Identifier(path) {\n // 对每个 Identifier 节点进行处理\n const name = path.node.name;\n path.node.name = name.toUpperCase();\n }\n }\n };\n};\n```\n\n5. 导出插件配置：为了让 Babel 可以识别你的插件，需要在插件函数中返回一个配置对象，其中 `visitor` 属性指定了你的插件要处理的 AST 节点类型和对应的处理函数。\n\n```javascript\nmodule.exports = function(babel) {\n const { types: t } = babel;\n\n return {\n visitor: {\n // ...\n }\n };\n};\n```\n\n6. 配置 Babel：在项目的 `.babelrc` 或 `babel.config.js` 文件中，将你的插件添加到 Babel 的插件列表中。\n\n```json\n{\n \"plugins\": [\"babel-plugin-custom-plugin\"]\n}\n```\n\n7. 使用插件：运行 Babel，它将根据你的配置和代码中的语法，应用插件并对代码进行转换。\n\n以上是编写 Babel 插件的基本步骤，可以根据具体需求和场景，实现各种自定义的转换、分析和操作逻辑。\n\n\n### babel 编写插件的时候有哪些核心方法\n\n在编写 Babel 插件时，可以使用以下核心方法来操作抽象语法树（AST）节点：\n\n1. `types` 对象： Babel 的 `types` 对象是你在插件中最常用的工具之一。它提供了一系列用于创建、访问和操作 AST 节点的方法。\n\n * `types.identifier(name)`: 创建一个标识符节点，表示一个变量或函数的名称。\n\n * `types.stringLiteral(value)`: 创建一个字符串字面量节点，表示一个字符串值。\n\n * `types.numericLiteral(value)`: 创建一个数值字面量节点，表示一个数字值。\n\n * `types.booleanLiteral(value)`: 创建一个布尔字面量节点，表示一个布尔值。\n\n * `types.objectExpression(properties)`: 创建一个对象表达式节点，表示一个对象字面量。\n\n * `types.arrayExpression(elements)`: 创建一个数组表达式节点，表示一个数组字面量。\n\n * `types.callExpression(callee, arguments)`: 创建一个函数调用表达式节点，表示一个函数的调用。\n\n * `types.memberExpression(object, property)`: 创建一个成员表达式节点，表示一个对象的成员访问。\n\n 这些方法可以帮助你构建新的 AST 节点或访问现有的 AST 节点。\n\n2. `path` 对象： Babel 的 `path` 对象代表 AST 中的一个路径，你可以通过该对象访问和操作 AST 节点。在插件的处理函数中，你将会经常使用 `path` 对象。\n\n * `path.node`: 访问当前路径对应的节点。\n\n * `path.parent`: 访问当前路径的父路径。\n\n * `path.scope`: 访问当前路径的作用域。\n\n * `path.traverse(visitor)`: 遍历当前路径的子路径，使用指定的访问者函数。\n\n * `path.replaceWith(node)`: 替换当前路径的节点。\n\n * `path.remove()`: 移除当前路径的节点。\n\n 这些方法可以帮助你在遍历 AST 树时对节点进行修改、替换或删除。\n\n3. `traverse` 方法： `babel-traverse` 是 Babel 提供的一个独立的模块，用于遍历和操作 AST。在插件中，你可以使用 `traverse` 方法来遍历 AST 树并应用你的插件逻辑。\n\n * `traverse(ast, visitor)`: 使用指定的访问者函数遍历给定的 AST 树。\n\n `visitor` 是一个对象，其中包含了处理不同类型节点的方法。通过在 `visitor` 对象中定义相应类型节点的处理函数，你可以在遍历过程中针对特定类型的节点执行你的插件逻辑。\n\n4. `babel.template` 方法： `babel-template` 是 Babel 提供的一个独立模块，用于根据字符串模板生成 AST 节点。你可以使用 `babel.template` 方法来创建包含特定模板结构的 AST 节点。\n\n * `babel.template(code, options)`: 根据指定的代码模板生成 AST 节点。\n\n `code` 参数是一个包含要生成的代码模板的字符串，而 `options` 参数可以指定一些配置选项，如 `preserveComments` 来保留注释。该方法将返回一个函数，调用该函数并传入替换模板中的变量值，即可生成对应的 AST 节点。\n\n 通过使用 `babel.template` 方法，你可以更方便地创建复杂的 AST 节点结构，尤其在需要生成大量相似结构的节点时非常有用。\n\n5. `babel.transform` 方法： `babel-transform` 是 Babel 提供的一个独立模块，用于将 JavaScript 代码转换为 AST 或将 AST 转换回 JavaScript 代码。在编写插件时，你可以使用 `babel.transform` 方法来进行代码转换操作。\n\n * `babel.transform(code, options)`: 将指定的代码转换为 AST 或将 AST 转换回代码。\n\n `code` 参数是一个包含要转换的 JavaScript 代码的字符串，而 `options` 参数可以指定一些配置选项，如 `plugins` 来指定要应用的插件。该方法将返回一个包含 `ast` 和 `code` 属性的对象，`ast` 属性表示生成的 AST 树，`code` 属性表示转换后的代码。\n\n 通过使用 `babel.transform` 方法，你可以在插件内部对代码进行转换和处理，将代码转换为 AST 进行修改，然后再将修改后的 AST 转换回代码。\n\n\n### 编写一个去除代码里面 console.log 的 babel 插件\n\n以下是一个简单的 Babel 插件示例，用于去除代码中的 `console.log` 语句：\n\n```javascript\n// babel-plugin-remove-console.js\n\nmodule.exports = function ({ types: t }) {\n return {\n visitor: {\n // 处理函数调用表达式\n CallExpression(path) {\n const { callee } = path.node;\n\n // 如果函数调用的名称是 console.log\n if (\n t.isMemberExpression(callee) &&\n t.isIdentifier(callee.object, { name: 'console' }) &&\n t.isIdentifier(callee.property, { name: 'log' })\n ) {\n // 移除该函数调用\n path.remove();\n }\n }\n }\n };\n};\n```\n\n该插件会遍历代码中的函数调用表达式，如果发现是 `console.log`，则会移除该函数调用。\n\n要使用该插件，可以在项目中安装并配置它。例如，创建一个 `.babelrc` 文件，并将该插件添加到 Babel 的插件列表中：\n\n```json\n{\n \"plugins\": [\"./path/to/babel-plugin-remove-console.js\"]\n}\n```\n\n然后运行 Babel 命令或构建工具，它将应用该插件，并从代码中去除所有的 `console.log` 语句。\n\n请注意，这只是一个简单的示例插件，仅适用于演示目的。在实际开发中，你可能需要更复杂的逻辑来处理不同的情况和要求。\n\n\n\n\n",{"_58":576,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/377/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/377/timeline",{"_58":579,"_60":61,"_62":580,"_64":581,"_66":582,"_68":583,"_70":584,"_72":585,"_74":586,"_76":587,"_78":588,"_111":589,"_131":132,"_133":24,"_134":-5,"_135":592,"_137":593,"_159":152,"_153":595,"_155":595,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":596,"_169":597,"_175":598,"_177":599,"_189":601,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/376","https://api.github.com/repos/pro-collection/interview-question/issues/376/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/376/comments","https://api.github.com/repos/pro-collection/interview-question/issues/376/events","https://github.com/pro-collection/interview-question/issues/376",1722347307,"I_kwDOJGDC6c5mqO8r",376,"SSR 了解多少【热度: 486】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[590,591],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":294,"_72":295,"_58":296,"_117":297,"_119":129,"_121":24,"_122":130},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":594,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-05-23T15:45:51Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：SSR 原理、SSR 实现\n\n### SSR 原理是啥\n\n服务器端渲染（Server-Side Rendering，SSR）是一种前端渲染方式，其核心原理是在服务器端将动态生成的 HTML 页面发送给客户端，以便客户端在接收到页面时直接渲染显示，而不是在客户端使用 JavaScript 动态生成页面。\n\n核心原理如下：\n\n1. 客户端发起请求：当用户访问一个 SSR 应用的页面时，客户端会向服务器发起请求。\n\n2. 服务器处理请求：服务器接收到请求后，根据请求的路径和参数，获取对应的数据。\n\n3. 数据获取和页面渲染：在服务器端，通过调用后端数据接口或其他数据源获取页面所需的数据。获取到数据后，服务器使用模板引擎或渲染框架将数据填充到页面模板中，生成完整的 HTML 页面。\n\n4. HTML 页面返回给客户端：服务器将生成的 HTML 页面作为响应返回给客户端。\n\n5. 客户端渲染：客户端接收到服务器返回的 HTML 页面后，直接渲染显示页面内容。由于服务器已经将数据填充到了页面中，客户端无需再进行数据获取和页面渲染的过程，提升了页面的加载速度和用户体验。\n\nSSR 的核心原理是在服务器端生成完整的 HTML 页面，并将其发送给客户端，使客户端能够更快地显示页面内容。相比于传统的客户端渲染（CSR），SSR 可以改善首次加载时的白屏时间和搜索引擎抓取等方面的问题。同时，SSR 也可以更好地支持 SEO（搜索引擎优化）和提供更好的性能体验给用户。\n\n\n### 实现方案\n\n前端实现服务器端渲染（SSR）的方案有以下几种：\n\n1. 基于 Node.js 的框架：使用 Node.js 的框架（如Express、Koa、Nest.js等）来构建服务器端应用程序，并在服务器端进行页面渲染。通过在服务器上运行 JavaScript 代码，将渲染好的页面直接返回给客户端。\n\n2. 框架提供的 SSR 功能：一些前端框架（如Next.js、Nuxt.js、Angular Universal等）提供了内置的服务器端渲染功能，可以更方便地实现 SSR。这些框架会负责处理路由、数据预取和页面渲染等工作，并将渲染好的页面返回给客户端。\n\n3. 预渲染：使用预渲染技术将静态页面提前生成，并部署到服务器上。在用户请求页面时，直接返回预渲染好的 HTML 页面，然后再由客户端接管页面的交互。这种方式适用于内容不经常变动或不需要动态数据的页面。\n\n4. 后端代理：通过将前端应用程序的请求代理到服务器端，然后在服务器端进行页面渲染，并将渲染好的页面返回给客户端。这种方式适用于在现有的后端服务中添加 SSR 功能，而无需重写整个应用程序。\n\n需要根据具体的项目需求、技术栈和框架选择合适的 SSR 实现方案。每种方案都有其优点和限制，综合考虑性能、开发体验、部署成本和维护复杂度等因素来做出决策。\n\n",{"_58":600,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/376/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/376/timeline",{"_58":603,"_60":61,"_62":604,"_64":605,"_66":606,"_68":607,"_70":608,"_72":609,"_74":610,"_76":611,"_78":612,"_111":613,"_131":132,"_133":24,"_134":-5,"_135":616,"_137":617,"_159":152,"_153":619,"_155":620,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":621,"_169":622,"_175":623,"_177":624,"_189":626,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/373","https://api.github.com/repos/pro-collection/interview-question/issues/373/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/373/comments","https://api.github.com/repos/pro-collection/interview-question/issues/373/events","https://github.com/pro-collection/interview-question/issues/373",1722310035,"I_kwDOJGDC6c5mqF2T",373,"Babel Polyfill 了解多少【热度: 200】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[614,615],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":323,"_72":324,"_58":325,"_117":326,"_119":129,"_121":24,"_122":130},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":618,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-05-23T15:27:13Z","2023-05-23T15:27:14Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：Babel Polyfill 原理、Babel Polyfill 作用、Babel Polyfill 使用、Babel Polyfill 按需加载\n\n### Babel Polyfill 作用是啥\n\nBabel Polyfill 的作用是在旧版本浏览器中提供对新的JavaScript特性和API的支持。当使用Babel进行代码转换时，它只会转换语法，而不会转换新的API和全局对象（如Promise、Map、Set等）。\n\n旧版本的浏览器可能不支持这些新的API和全局对象，因此在运行使用这些特性的代码时会抛出错误。为了解决这个问题，可以使用Babel Polyfill来填充缺失的功能，以确保代码在旧版本浏览器中正常运行。\n\nBabel Polyfill通过修改全局对象和原型链，添加缺失的方法和属性，使得代码能够在不支持这些功能的浏览器中运行。它会检测当前环境的特性支持情况，并根据需要自动加载所需的Polyfill代码。\n\n使用Babel Polyfill可以让开发人员在编写代码时不必过多考虑浏览器的兼容性，而专注于使用最新的JavaScript特性和API。它提供了一种简单方便的方式来填充浏览器的功能差异，确保代码在各种浏览器环境中具有一致的行为。\n\n\n### 如何使用\n\n要使用 Babel Polyfill，需要按照以下步骤进行设置：\n\n1. 安装依赖：首先，确保你的项目已经安装了 Babel 相关的依赖包。这包括 `@babel/core`、`@babel/preset-env` 和 `@babel/polyfill`。你可以使用 npm 或者 yarn 进行安装：\n\n```shell\nnpm install --save-dev @babel/core @babel/preset-env @babel/polyfill\n```\n\n2. 配置 Babel：在项目根目录下创建一个 `.babelrc` 文件，并添加以下配置：\n\n```json\n{\n \"presets\": [\"@babel/preset-env\"]\n}\n```\n\n这样的配置将告诉 Babel 使用 `@babel/preset-env` 预设来进行转换。\n\n3. 导入 Polyfill：在你的入口文件（通常是项目的主 JavaScript 文件）中导入 Babel Polyfill。你可以使用 import 语句或者 require 来导入 Polyfill：\n\n使用 import（适用于 ES6 模块）：\n\n```javascript\nimport '@babel/polyfill';\n```\n\n使用 require（适用于 CommonJS 模块）：\n\n```javascript\nrequire('@babel/polyfill');\n```\n\n导入 Polyfill 的位置很重要，通常应该在你的应用程序代码之前导入，以确保 Polyfill 在应用程序代码之前被加载和执行。\n\n4. 配置目标浏览器：为了让 Babel Polyfill 根据目标浏览器进行特性填充，你可以在 `.babelrc` 文件中的 `@babel/preset-env` 配置中指定目标浏览器的选项。例如，你可以在配置中添加 `targets` 属性：\n\n```json\n{\n \"presets\": [\n [\n \"@babel/preset-env\",\n {\n \"targets\": {\n \"browsers\": [\"last 2 versions\", \"ie >= 11\"]\n }\n }\n ]\n ]\n}\n```\n\n这样，Polyfill 将根据所选的目标浏览器填充相应的功能。\n\n完成以上步骤后，Babel Polyfill 将根据配置在目标浏览器中填充所需的功能，以确保你的代码在旧版本浏览器中正常运行。请注意，Polyfill 会增加你的应用程序的大小，因此请考虑仅填充所需的功能，以减小文件大小并优化性能。\n\n\n### 按需加载 Polyfill\n\nBabel Polyfill 默认会填充所有缺失的功能，但如果你只需要按需加载特定功能，可以使用 core-js 库的按需加载特性。下面是按需加载 Babel Polyfill 的步骤：\n\n1. 安装依赖：确保你的项目已经安装了必要的依赖。除了之前提到的 Babel 相关依赖外，你还需要安装 `core-js`。\n\n```shell\nnpm install --save-dev @babel/core @babel/preset-env core-js\n```\n\n2. 配置 Babel：在 `.babelrc` 文件中，添加以下配置：\n\n```json\n{\n \"presets\": [\n [\n \"@babel/preset-env\",\n {\n \"useBuiltIns\": \"usage\",\n \"corejs\": 3\n }\n ]\n ]\n}\n```\n\n`useBuiltIns` 选项设置为 `\"usage\"` 表示按需加载特性，而 `\"corejs\": 3` 指定了使用的 `core-js` 版本。\n\n3. 导入 Polyfill：在需要使用特定功能的文件中，按需导入所需的 Polyfill。例如，如果你需要填充 `Promise` 和 `Array.prototype.includes`，你可以按如下方式导入：\n\n```javascript\nimport 'core-js/features/promise';\nimport 'core-js/features/array/includes';\n```\n\n这样只会加载和填充所需的功能，而不会加载整个 Polyfill 库。你可以根据具体的功能需求进行按需导入。\n\n请注意，使用按需加载的方式可以减小应用程序的文件大小，并且只填充需要的功能，但需要确保在使用相关功能之前已经导入了相应的 Polyfill。\n\n\n\n",{"_58":625,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/373/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/373/timeline",{"_58":628,"_60":61,"_62":629,"_64":630,"_66":631,"_68":632,"_70":633,"_72":634,"_74":635,"_76":636,"_78":637,"_111":638,"_131":132,"_133":24,"_134":-5,"_135":641,"_137":642,"_159":152,"_153":644,"_155":644,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":645,"_169":646,"_175":647,"_177":648,"_189":650,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/372","https://api.github.com/repos/pro-collection/interview-question/issues/372/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/372/comments","https://api.github.com/repos/pro-collection/interview-question/issues/372/events","https://github.com/pro-collection/interview-question/issues/372",1722271208,"I_kwDOJGDC6c5mp8Xo",372,"幽灵依赖是什么",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[639,640],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":323,"_72":324,"_58":325,"_117":326,"_119":129,"_121":24,"_122":130},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":643,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-05-23T15:04:38Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"### 幽灵依赖是什么\n\n\"幽灵依赖\"（Ghost Dependency）是指在项目的`node_modules`目录中存在但未被实际使用的依赖包。\n\n在使用 npm 或者其他包管理工具安装依赖包时，有时会出现安装了一些不需要的或者不正确的依赖包的情况。这些依赖包在项目中没有被显式地引用或使用，但仍然存在于`node_modules`目录中，占用了项目的存储空间。\n\n幽灵依赖可能会产生以下问题：\n\n1. 占用存储空间：未使用的依赖包会增加项目的体积，占用存储空间。对于大型项目或频繁部署的项目来说，这可能会造成不必要的存储资源浪费。\n\n2. 增加构建时间：未使用的依赖包可能会增加构建过程中的解析和处理时间，导致构建过程变慢。这会影响开发人员的开发效率和项目的部署速度。\n\n3. 潜在的安全风险：未使用的依赖包可能包含漏洞或安全风险，但由于没有使用，可能没有及时更新或修复这些问题，增加了项目的安全隐患。\n\n为了解决幽灵依赖的问题，可以采取以下措施：\n\n1. 定期检查依赖：定期检查项目的依赖，识别和删除未使用的依赖包。可以使用工具如`npm-check-unused`、`depcheck`等来帮助检测和清理未使用的依赖。\n\n2. 精简依赖：审查项目的依赖关系，仅安装和保留必要的依赖包。避免过度依赖，只安装项目所需的模块，减少项目体积和构建时间。\n\n3. 更新依赖包：确保项目中使用的依赖包都是最新版本，并及时更新已知的安全漏洞和问题。这可以通过定期检查依赖包的更新和使用工具如`npm audit`来实现。\n\n通过处理幽灵依赖，可以提高项目的整洁性、性能和安全性，并减少不必要的开销和风险。\n\n\n### pnpm 是如何解决幽灵依赖问题的\n\npnpm 是一个基于 npm 的包管理工具，它采用了一种称为\"快速硬链接（Fast Hard Links）\"的机制来解决幽灵依赖问题。\n\n传统的 npm 或 yarn 安装依赖时，每个项目都会在`node_modules`目录下创建依赖包的副本。这导致了大量的重复文件，尤其是对于多个项目都使用同一依赖包时。\n\n而 pnpm 通过使用快速硬链接机制，在全局的存储位置（默认为`~/.pnpm-store`）只保存一份依赖包，而不是为每个项目都复制一份。这样就避免了幽灵依赖问题，减少了存储空间的占用。\n\n当使用 pnpm 安装依赖时，它会在项目的`node_modules`目录下创建一个`.modules.yaml`文件，记录项目所需的依赖包和版本信息。实际的依赖包文件通过硬链接指向全局存储位置中的依赖包。这意味着不同项目之间可以共享相同的依赖包，但每个项目都拥有自己的依赖版本。\n\n通过这种方式，pnpm 解决了幽灵依赖的问题，同时减少了存储空间的使用。它还具有一些其他的优点，如更快的安装速度、更少的网络传输和更好的缓存利用率。\n\n需要注意的是，pnpm 仍然会将项目中的所有依赖安装在`node_modules`目录下，但它使用硬链接的方式避免了重复文件的复制，从而解决了幽灵依赖问题。\n",{"_58":649,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/372/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/372/timeline",{"_58":652,"_60":61,"_62":653,"_64":654,"_66":655,"_68":656,"_70":657,"_72":658,"_74":659,"_76":660,"_78":661,"_111":662,"_131":132,"_133":24,"_134":-5,"_135":665,"_137":666,"_159":152,"_153":668,"_155":669,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":670,"_169":671,"_175":672,"_177":673,"_189":675,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/357","https://api.github.com/repos/pro-collection/interview-question/issues/357/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/357/comments","https://api.github.com/repos/pro-collection/interview-question/issues/357/events","https://github.com/pro-collection/interview-question/issues/357",1712214414,"I_kwDOJGDC6c5mDlGO",357,"如何将JavaScript代码解析成抽象语法树(AST)【热度: 1,169】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[663,664],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":125,"_72":126,"_58":127,"_117":128,"_119":129,"_121":24,"_122":130},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":667,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-05-16T15:03:24Z","2023-05-16T15:03:25Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：解析为 AST、抽象语法树、AST 词法分析、AST 语法分析\n\n### 如何将JavaScript代码解析成抽象语法树\n\n要将JavaScript代码解析成抽象语法树（Abstract Syntax Tree，AST），你可以使用工具或库来实现。以下是几种常用的方法：\n\n1. Esprima: Esprima 是一个流行的JavaScript解析器，它可以将JavaScript代码解析成AST。你可以使用它的 JavaScript API 来将代码解析成AST对象。\n\n```javascript\nconst esprima = require('esprima');\nconst code = 'var x = 5;';\nconst ast = esprima.parseScript(code);\nconsole.log(ast);\n```\n\n2. Acorn: Acorn 是另一个广泛使用的JavaScript解析器，它也可以将JavaScript代码解析成AST。你可以使用它的 JavaScript API 来解析代码并获取AST对象。\n\n```javascript\nconst acorn = require('acorn');\nconst code = 'var x = 5;';\nconst ast = acorn.parse(code, { ecmaVersion: 2020 });\nconsole.log(ast);\n```\n\n3. Babel: Babel 是一个功能强大的JavaScript编译器，它可以将代码转换为AST，并提供了丰富的插件系统，用于转换和操作AST。你可以使用 Babel 的 API 来解析代码并获取AST对象。\n\n```javascript\nconst babelParser = require('@babel/parser');\nconst code = 'const x = 5;';\nconst ast = babelParser.parse(code, { sourceType: 'module' });\nconsole.log(ast);\n```\n\n这些工具和库都可以将JavaScript代码解析成AST对象，从而使你能够对代码进行进一步的分析、转换或处理。你可以根据自己的需求选择其中之一，并根据其文档了解更多关于解析选项和AST节点的信息。\n\n\n### JavaScript代码解析成抽象语法树的原理是什么\n\nJavaScript代码解析成抽象语法树（Abstract Syntax Tree，AST）的过程涉及以下几个主要步骤：\n\n1. 词法分析（Lexical Analysis）：词法分析器（Lexer）将源代码拆分成词法单元（tokens），比如变量名、关键字、操作符、标点符号等。它根据一组定义好的规则（词法规范）来识别和分类这些词法单元。\n\n2. 语法分析（Syntax Analysis）：语法分析器（Parser）接收词法分析器生成的词法单元，并根据语法规则构建AST。语法分析器使用上下文无关文法（Context-Free Grammar）来定义语言的语法规则，它通过递归下降、LR(1) 等算法来处理这些规则，以确定输入是否符合语法规则并生成相应的AST。\n\n3. 构建AST：在语法分析的过程中，语法分析器根据语法规则构建AST。AST是一个树状结构，其中每个节点表示源代码中的一个语法结构，如表达式、语句、函数等。不同节点类型代表不同的语法结构，它们之间通过父子关系和兄弟关系来表示源代码的层次结构和逻辑关联。\n\n4. 后续处理：生成AST后，可以进行进一步的处理和分析。这可能包括语义分析、类型推断、符号解析、代码优化等。这些步骤可以根据具体的需求和工具进行。\n\n总结：将JavaScript代码解析成AST的过程是通过词法分析器将源代码拆分成词法单元，然后语法分析器根据语法规则构建AST。AST提供了对代码结构的抽象表示，便于进一步分析、转换和操作代码。\n",{"_58":674,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/357/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/357/timeline",{"_58":677,"_60":61,"_62":678,"_64":679,"_66":680,"_68":681,"_70":682,"_72":683,"_74":684,"_76":685,"_78":686,"_111":687,"_131":132,"_133":24,"_134":-5,"_135":690,"_137":691,"_159":152,"_153":693,"_155":694,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":695,"_169":696,"_175":697,"_177":698,"_189":700,"_191":-5,"_192":-5,"_193":194},"https://api.github.com/repos/pro-collection/interview-question/issues/341","https://api.github.com/repos/pro-collection/interview-question/issues/341/labels{/name}","https://api.github.com/repos/pro-collection/interview-question/issues/341/comments","https://api.github.com/repos/pro-collection/interview-question/issues/341/events","https://github.com/pro-collection/interview-question/issues/341",1698600860,"I_kwDOJGDC6c5lPpec",341,"npm script 生命周期有哪些?【热度: 519】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[688,689],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":430,"_72":431,"_58":432,"_117":433,"_119":129,"_121":24,"_122":130},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":692,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-05-06T12:00:10Z","2023-05-06T12:10:45Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：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",{"_58":699,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/341/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/341/timeline",{"_58":702,"_60":61,"_62":703,"_64":704,"_66":705,"_68":706,"_70":707,"_72":708,"_74":709,"_76":710,"_78":711,"_111":712,"_131":132,"_133":24,"_134":-5,"_135":715,"_137":716,"_159":152,"_153":718,"_155":718,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":719,"_169":720,"_175":721,"_177":722,"_189":724,"_191":-5,"_192":-5,"_193":194},"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】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[713,714],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":402,"_72":403,"_58":404,"_117":405,"_119":129,"_121":24,"_122":130},[],{"_58":211,"_68":212,"_62":213,"_70":214,"_72":215,"_74":216,"_76":217,"_122":218,"_147":717,"_149":220,"_151":152,"_131":132,"_153":221,"_155":222,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-04-26T15:28:50Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：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",{"_58":723,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/316/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/316/timeline",{"_58":726,"_60":61,"_62":727,"_64":728,"_66":729,"_68":730,"_70":731,"_72":732,"_74":733,"_76":734,"_78":735,"_111":736,"_131":132,"_133":24,"_134":-5,"_135":739,"_137":740,"_159":152,"_153":753,"_155":754,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":755,"_169":756,"_175":757,"_177":758,"_189":760,"_191":-5,"_192":-5,"_193":194},"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】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[737,738],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":430,"_72":431,"_58":432,"_117":433,"_119":129,"_121":24,"_122":130},[],{"_58":741,"_68":742,"_62":743,"_70":744,"_72":745,"_74":746,"_76":747,"_122":748,"_147":749,"_149":750,"_151":152,"_131":132,"_153":751,"_155":752,"_157":-5,"_158":-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,"中","中级程序面试问题",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},510,"2023-03-06T15:00:15Z","2025-09-07T06:08:31Z","2023-04-26T15:15:58Z","2023-04-26T15:16:44Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：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",{"_58":759,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/315/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/315/timeline",{"_58":762,"_60":61,"_62":763,"_64":764,"_66":765,"_68":766,"_70":767,"_72":768,"_74":769,"_76":770,"_78":771,"_111":772,"_131":132,"_133":24,"_134":-5,"_135":775,"_137":776,"_159":152,"_153":778,"_155":778,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":779,"_169":780,"_175":781,"_177":782,"_189":784,"_191":-5,"_192":-5,"_193":194},"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】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[773,774],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":430,"_72":431,"_58":432,"_117":433,"_119":129,"_121":24,"_122":130},[],{"_58":741,"_68":742,"_62":743,"_70":744,"_72":745,"_74":746,"_76":747,"_122":748,"_147":777,"_149":750,"_151":152,"_131":132,"_153":751,"_155":752,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-04-26T15:05:23Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"**关键词**：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",{"_58":783,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/314/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/314/timeline",{"_58":786,"_60":61,"_62":787,"_64":788,"_66":789,"_68":790,"_70":791,"_72":792,"_74":793,"_76":794,"_78":795,"_111":796,"_131":132,"_133":24,"_134":-5,"_135":798,"_137":799,"_159":746,"_153":801,"_155":802,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":803,"_169":804,"_175":805,"_177":806,"_189":808,"_191":-5,"_192":-5,"_193":194},"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）了解多少？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[797],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":741,"_68":742,"_62":743,"_70":744,"_72":745,"_74":746,"_76":747,"_122":748,"_147":800,"_149":750,"_151":152,"_131":132,"_153":751,"_155":752,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-04-26T14:40:53Z","2023-09-12T14:13:38Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"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",{"_58":807,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/313/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/313/timeline",{"_58":810,"_60":61,"_62":811,"_64":812,"_66":813,"_68":814,"_70":815,"_72":816,"_74":817,"_76":818,"_78":819,"_111":820,"_131":132,"_133":24,"_134":-5,"_135":822,"_137":823,"_159":152,"_153":825,"_155":826,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":827,"_169":828,"_175":829,"_177":830,"_189":832,"_191":-5,"_192":-5,"_193":194},"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】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[821],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":741,"_68":742,"_62":743,"_70":744,"_72":745,"_74":746,"_76":747,"_122":748,"_147":824,"_149":750,"_151":152,"_131":132,"_153":751,"_155":752,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-04-26T14:20:39Z","2023-04-26T14:23:07Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"### 什么是 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```",{"_58":831,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/312/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/312/timeline",{"_58":834,"_60":61,"_62":835,"_64":836,"_66":837,"_68":838,"_70":839,"_72":840,"_74":841,"_76":842,"_78":843,"_111":844,"_131":132,"_133":24,"_134":-5,"_135":846,"_137":847,"_159":152,"_153":849,"_155":850,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":851,"_169":852,"_175":853,"_177":854,"_189":856,"_191":-5,"_192":-5,"_193":194},"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】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[845],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":741,"_68":742,"_62":743,"_70":744,"_72":745,"_74":746,"_76":747,"_122":748,"_147":848,"_149":750,"_151":152,"_131":132,"_153":751,"_155":752,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-04-26T14:13:01Z","2023-04-26T14:13:02Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"`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",{"_58":855,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/311/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/311/timeline",{"_58":858,"_60":61,"_62":859,"_64":860,"_66":861,"_68":862,"_70":863,"_72":864,"_74":865,"_76":866,"_78":867,"_111":868,"_131":132,"_133":24,"_134":-5,"_135":870,"_137":871,"_159":152,"_153":873,"_155":874,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":875,"_169":876,"_175":877,"_177":878,"_189":880,"_191":-5,"_192":-5,"_193":194},"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】",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[869],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":741,"_68":742,"_62":743,"_70":744,"_72":745,"_74":746,"_76":747,"_122":748,"_147":872,"_149":750,"_151":152,"_131":132,"_153":751,"_155":752,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-04-26T13:01:07Z","2023-04-26T13:02:02Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"首先上图： \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",{"_58":879,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/309/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/309/timeline",{"_58":882,"_60":61,"_62":883,"_64":884,"_66":885,"_68":886,"_70":887,"_72":888,"_74":889,"_76":890,"_78":891,"_111":892,"_131":132,"_133":24,"_134":-5,"_135":894,"_137":895,"_159":152,"_153":897,"_155":898,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":899,"_169":900,"_175":901,"_177":902,"_189":904,"_191":-5,"_192":-5,"_193":194},"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] 分包的方式有哪些？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[893],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":896,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-04-16T14:37:43Z","2023-04-16T14:37:44Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"### 在 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",{"_58":903,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/289/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/289/timeline",{"_58":906,"_60":61,"_62":907,"_64":908,"_66":909,"_68":910,"_70":911,"_72":912,"_74":913,"_76":914,"_78":915,"_111":916,"_131":132,"_133":24,"_134":-5,"_135":919,"_137":920,"_159":152,"_153":922,"_155":922,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":923,"_169":924,"_175":925,"_177":926,"_189":928,"_191":-5,"_192":-5,"_193":194},"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 作用是啥？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[917,918],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":402,"_72":403,"_58":404,"_117":405,"_119":129,"_121":24,"_122":130},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":921,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-04-16T14:30:00Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"`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` 配置项需要谨慎，因为如果在运行时无法正确获取到指定的外部依赖，就会导致代码运行出错。",{"_58":927,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/288/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/288/timeline",{"_58":930,"_60":61,"_62":931,"_64":932,"_66":933,"_68":934,"_70":935,"_72":936,"_74":937,"_76":938,"_78":939,"_111":940,"_131":132,"_133":24,"_134":-5,"_135":943,"_137":944,"_159":152,"_153":946,"_155":947,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":948,"_169":949,"_175":950,"_177":951,"_189":953,"_191":-5,"_192":-5,"_193":194},"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] 异步加载原理是啥",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[941,942],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},{"_70":402,"_72":403,"_58":404,"_117":405,"_119":129,"_121":24,"_122":130},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":945,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-04-16T14:27:01Z","2023-04-16T14:27:02Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"### 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",{"_58":952,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/287/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/287/timeline",{"_58":955,"_60":61,"_62":956,"_64":957,"_66":958,"_68":959,"_70":960,"_72":961,"_74":962,"_76":963,"_78":964,"_111":965,"_131":132,"_133":24,"_134":-5,"_135":967,"_137":968,"_159":194,"_153":970,"_155":971,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":972,"_169":973,"_175":974,"_177":975,"_189":977,"_191":-5,"_192":-5,"_193":194},"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 的设计思路与实现原理是什么？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[966],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":211,"_68":212,"_62":213,"_70":214,"_72":215,"_74":216,"_76":217,"_122":218,"_147":969,"_149":220,"_151":152,"_131":132,"_153":221,"_155":222,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-04-12T14:51:55Z","2023-04-12T14:56:38Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"### 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",{"_58":976,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/284/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/284/timeline",{"_58":979,"_60":61,"_62":980,"_64":981,"_66":982,"_68":983,"_70":984,"_72":985,"_74":986,"_76":987,"_78":988,"_111":989,"_131":132,"_133":24,"_134":-5,"_135":991,"_137":992,"_159":194,"_153":994,"_155":995,"_158":-5,"_161":162,"_106":-5,"_163":-5,"_164":996,"_169":997,"_175":998,"_177":999,"_189":1001,"_191":-5,"_192":-5,"_193":194},"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] 构建流程是怎么样的？",{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},[990],{"_70":114,"_72":115,"_58":116,"_117":118,"_119":120,"_121":24,"_122":123},[],{"_58":139,"_68":140,"_62":141,"_70":142,"_72":143,"_74":144,"_76":145,"_122":146,"_147":993,"_149":150,"_151":152,"_131":132,"_153":154,"_155":156,"_157":-5,"_158":-5},{"_80":81,"_70":82,"_72":83,"_84":85,"_86":28,"_58":87,"_68":88,"_89":90,"_91":92,"_93":94,"_95":96,"_97":98,"_99":100,"_101":102,"_66":103,"_104":105,"_106":107,"_108":109,"_110":24},"2023-04-12T14:25:39Z","2023-05-31T14:45:00Z",{"_166":152,"_167":152,"_168":152},{"_171":152,"_172":152,"_173":152,"_174":152},"`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",{"_58":1000,"_180":152,"_181":152,"_182":152,"_183":152,"_184":152,"_185":152,"_186":152,"_187":152,"_188":152},"https://api.github.com/repos/pro-collection/interview-question/issues/283/reactions","https://api.github.com/repos/pro-collection/interview-question/issues/283/timeline","pagination",{"_1004":1005,"_166":1006},"value",5,6,"actionData","errors"]