SharePoint Framework 1.22 采用了基于 Heft 的构建工具链并刷新了项目基线
微软正式发布SharePoint Framework (SPFx) 1.22版本,该版本专注于现代化 SPFx 开发者的构建和工具使用体验。这一转变标志着 SPFx 解决方案构建方式的基础性更新,旨在解决技术债务、提升可扩展性,并与更广泛的微软工具链标准保持一致。 在此之前,SPFx 项目依赖基于Gulp的构建工具链来协调编译、打包等任务。尽管这种方式被大家所熟知,但相对于现代化的 JavaScript 和 TypeScript 工作流来说,这种模式早已被认为是过时的。同时,旧版 SPFx 的模板和生成器输出触发了 SPFx 1.22 更新的核心是从基于 Gulp 的工具链转向基于Heft的工具链。Heft(来自 Rush Stack 生态系统的配置驱动的构建编排器)现在为新的 SPFx 项目管理构建任务,而底层的打包继续使用 Webpack。这一转变使 SPFx 的开发与当代构建生态系统保持一致,使得构建更加透明、可维护,并便于未来的工具增强。如果需要的话,现有项目升级到 1.22 后可以继续使用传统的 Gulp 工作流,但使用 Yeoman 新建的项目默认采用 Heft。 Heft 的引入解决了长期以来开发者对 SPFx 工具链类似“黑箱”的担忧。据微软介绍,Heft 具备带有明确的倾向性和基于插件功能的设计,允许实现更透明、更易于维护的构建,并有助于未来工具的改进。它支持共享配置( 此次发布的另一个重要现代化措施是解决了 SPFx Yeoman 生成器和脚手架项目输出中由 此次发布没有对先前支持的 API 引入任何功能弃用(deprecations)。然而,微软明确指出,未来将仅对旧版 Gulp 构建系统提供关键性修复。在即将发布的 SPFx 1.23 版本中,新建项目将仅使用 Heft(前提是 CLI 工具已准备就绪)。到 SPFx 1.24,基于 Gulp 的构建管道将被正式标记为不支持(officially unsupported)。这意味着开发者应尽早规划迁移路径,尤其是依赖自定义 Gulp 任务的团队,以确保与未来 SPFx 版本的兼容性。 社区在社交媒体上的反应既表现出兴奋也带有一定的谨慎。在 LinkedIn 上,微软 365 开发者社区的成员强调了构建系统变更的重要性,指出“这不是一个简单的更新”,尤其是考虑到从 Gulp 到 Heft 的转换。一些开发者已经开始分享教程和资源以帮助他人适应新的 Heft 工作流。其他人则提到,迁移现有的项目是一项不小的挑战,尤其是对于拥有自定义 Gulp 任务或扩展的团队,并正在讨论逐步迁移的具体策略。 展望未来,SPFx 的路线图包括进一步解耦 CLI、开源模板以及与 Rush Stack 工具更深入的集成。鼓励开发者现在就开始探索 Heft,以熟悉未来的迁移路径并符合微软的发展方向。 关于完整的发布说明和 Heft 迁移指南,请参阅 SPFx 1.22发布说明和工具链文档。 原文链接: SharePoint Framework 1.22 Ships with Heft-Based Build Toolchain and Refreshed Project Baselinenpm audit漏洞,并落后于当前的依赖预期。1.2 版本通过过渡到新的工具链并清理脚手架解决方案中的漏洞解决了这些问题。rig.json),简化了 TypeScript 的设置,并提供了原生 Webpack 配置选项。然而,从自定义gulpfile.js进行迁移可能需要一些重要的调整,尤其是对于那些使用定制构建步骤的团队。npm audit报告的所有已知的安全漏洞。在使用最新的生成器生成一个新脚手架项目时,开发者将不会再看到npm audit报告的高严重性问题,从而提高了开箱即用的安全基线信心。微软还重置了脚手架模板中默认的 TypeScript 版本至 5.8,让开发者能够使用最新的语言特性及改进的工具支持。