尧图网页设计 
前端静态站点Web框架【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址https://gitcode.com/gh_mirrors/ga/gatsby点击查看免费下载导读gatsby3.7.0于 2021 年 6 月 8 日发布June 2021 #1是 Gatsby v3 时代极具里程碑意义的一个版本Functions服务端函数正式 GA不再需要实验性 flagwebpack 5 内置持久化缓存开启 20% 用户灰度Yarn 2PnP支持恢复同时引入面向源插件的新公共 actionunstable_createNodeManifest用于把 CMS 内容状态与最终构建页面关联起来、实验性的 LMDB 节点持久化存储以及gatsby-remark-images的decoding图片解码属性。本文以官方发布说明为骨架结合当前仓库源码逐项展开帮助你理解每个特性的设计动机、使用方式与底层实现。一、Functions服务端函数正式 GA从本版本开始Gatsby Functions在src/api目录下编写、部署为无服务器函数的后端代码正式成为一级特性generally available。此前的实验阶段用户不再需要配置任何FUNCTIONS之类的 flag 即可使用。相关示例可参考仓库 examples 目录下functions-*系列示例如 functions-hello-world、functions-basic-form、functions-auth0 等。在实现层面Functions 的构建与开发支持位于 Gatsby 核心包的 packages/gatsby/src/internal-plugins/functions/gatsby-node.ts该内部插件负责在gatsby develop/gatsby build期间扫描、编译并托管这些函数。从源码可以看到开发阶段的编译行为还受环境变量控制process.env.GATSBY_PRECOMPILE_DEVELOP_FUNCTIONS true || process.env.GATSBY_PRECOMPILE_DEVELOP_FUNCTIONS 1即设置GATSBY_PRECOMPILE_DEVELOP_FUNCTIONStrue可让开发服务器预编译函数从而加快首次请求的响应速度。Functions 的完整使用文档位于 docs/docs/reference/functions/index.md。二、webpack 持久化缓存从 flag 到 20% 灰度webpack 5 引入了内置的持久化缓存persistent caching能力webpack 可以复用上一次编译的产物显著加快编译步骤。Gatsby 在 v3.4 版本中以 flag 形式接入该特性而本版本开始向全体用户渐进式灰度默认对 20% 的用户启用。从当前仓库的 packages/gatsby/src/utils/webpack.config.js 可以看到该特性的实际接入方式——在build-javascript、build-html、develop、develop-html这四个编译阶段中注入 filesystem 缓存配置const cacheLocation path.join( program.directory, .cache, webpack, stage- stage ) const cacheConfig { type: filesystem, name: stage, cacheLocation, buildDependencies: { config: [__filename, ...pluginsPaths], }, } config.cache cacheConfig几个关键点分阶段缓存每个编译阶段stage有独立的name与缓存目录.cache/webpack/stage-stage避免不同 stage 的产物互相污染构建依赖追踪buildDependencies.config显式列出 webpack 配置文件自身以及所有实现了onCreateWebpackConfig的插件路径。一旦这些文件发生变化缓存即失效重建保证配置变更不会被陈旧缓存掩盖缓存位置位于项目根目录.cache/webpack/下属于本地构建缓存的一部分可随.cache一起清理。由于仍处于灰度阶段如果你在使用中遇到编译异常官方建议在 umbrella discussion 中反馈并可通过配置/环境变量显式控制该特性的开关。三、新 APIunstable_createNodeManifest与ownerNodeId这是本版本对源插件source plugin生态最重要的一次 API 扩展通过把「CMS 中某个内容的唯一修订状态manifest ID」与「由某个节点构建出的最终页面」建立映射让外部服务如 CMS 的 Preview 服务在构建完成后把请求路由到正确的页面。3.1 公共 actionunstable_createNodeManifest本版本在 packages/gatsby/src/redux/actions/public.js 中新增了公共 actionunstable_createNodeManifest类型为CREATE_NODE_MANIFEST。其签名与参数如下actions.unstable_createNodeManifest({ manifestId: post-id-1--updated-53154315, updatedAtUTC: 2021-07-08T21:52:28.79101:00, node: { id: post-id-1, }, })参数说明来自源码 JSDoc参数必填说明manifestId是一个将 manifest 与数据源唯一修订状态关联起来的 ID如 CMS 内容的 id 修订版本号node是要关联的 Gatsby 节点对象参考createNodeaction 的节点格式核心是node.idupdatedAtUTC否节点最近一次更新的时间。若省略则对每次调用都生成 manifest默认只为最近 30 天内更新过的内容生成 manifest可通过环境变量NODE_MANIFEST_MAX_DAYS_OLD调整窗口注意由于 API 仍处于不稳定阶段名称保留了unstable_前缀说明其接口在后续版本中仍可能调整。3.2createPage新增ownerNodeId参数为了让「节点 → 页面」的映射更准确本版本给createPagehelper 增加了ownerNodeId参数允许你显式声明某个页面「归属于」某个节点。在 packages/gatsby/src/redux/actions/public.js 中可以看到页面内部对象会保存该字段internalPage.ownerNodeId page.ownerNodeIdJSDoc 中也特别强调ownerNodeId指向的节点必须确实在该页面的 GraphQL 查询中被用到multiple nodes can be queried on a single page, this allows the user to tell us which node is the main node for the page。因为一个页面可能查询多个节点这个参数用于消除歧义。3.3 页面查找逻辑的优先级当 manifest 被处理时核心逻辑位于 packages/gatsby/src/utils/node-manifest.ts 的findPageOwnedByNode。源码中定义了完整的查找优先级FoundPageBy类型ownerNodeId页面显式声明的ownerNodeId nodeId最精确、最推荐filesystem-route-api页面的context.id nodeId且页面由gatsby-plugin-page-creator文件系统路由 API创建context.id页面 context 中存在与节点 id 匹配的id变量context.slug页面 context 中存在与节点slug匹配的slug变量queryTracking都没有时回退到查询追踪query tracking里第一个使用到该节点的页面none最终找不到页面。源码注释解释了兜底顺序的设计原因用id/slug作为 GraphQL 查询变量是常见写法因此即使没指定 owner也能作为比「随便抓第一个查询到该节点的页面」更好的猜测而queryTracking是最后手段。3.4 处理流程与产物processNodeManifests同样在 node-manifest.ts会统一处理待处理的 manifests使用fastq 并发队列并发数 25逐个处理避免大量 manifest 时发生栈溢出源码中特意用setImmediate规避受NODE_MANIFEST_FILE_LIMIT限制默认 10000可通过同名环境变量覆盖超限时按updatedAtUTC升序排序后只保留最早的部分优先写出每个 manifest 最终以 JSON 文件形式写入public/__node-manifests/pluginName/manifestId.jsonWindows 下会对:/\*?|\\等保留字符做替换以避免文件名非法见源码中对process.platform win32的分支处理处理结束后从 store 中清空待处理列表并在控制台输出统计信息如Wrote out N node page manifest file(s) in X ms若映射失败如找不到节点11804、找不到页面11801等会按错误 ID 汇总告警设置VERBOSE_NODE_MANIFESTtrue或gatsby_log_levelverbose可查看完整告警信息。最终效果正如发布说明所述源插件可以让 CMS 用一个 CMS ID 生成 manifest 文件该文件映射到 Gatsby 中最终构建完成的页面从而让外部服务在构建结束后把用户重定向到正确的页面如内容预览。四、实验特性LMDB 节点持久化存储本版本引入了一个实验性的数据存储选项LMDB通过lmdb/lmdb-store包实现。此前 Gatsby 的所有节点都保存在内存中的 Redux store 里遇到超大型站点时把 redux 状态持久化到磁盘可能导致OOM内存溢出。改用 LMDB 后节点被即时保存到这种持久化嵌入式存储中从而显著降低峰值内存占用并为此后的更多性能优化铺路。在当前仓库中该实验的实现位于 packages/gatsby/src/datastore/lmdb/lmdb-datastore.ts它基于lmdb包封装了数据存储层。从源码结构可以推断启用开关与环境变量相关if (process.env.GATSBY_EXPERIMENTAL_LMDB_INDEXES) { // 实验性的 LMDB 索引支持 }也就是说GATSBY_EXPERIMENTAL_LMDB_INDEXES控制的是 LMDB 索引层面的实验能力而整体启用 LMDB 存储的实验安装步骤以 Umbrella Discussion 中的说明为准。作为实验特性它仅推荐给希望降低大站点构建内存峰值的用户尝试并欢迎反馈问题。相关测试与查询支持代码位于 packages/gatsby/src/datastore/lmdb/query/包含基于索引的过滤查询、索引建议等可进一步了解其能力边界。五、gatsby-remark-images默认启用异步图片解码本版本为gatsby-remark-images插件新增了decoding选项用于给插件产出的所有img标签添加对应的decoding属性默认值为async允许的取值为async、sync、auto。5.1 配置方式在gatsby-config.js中配置插件即可module.exports { plugins: [ { resolve: gatsby-remark-images, options: { // 默认值即 async按需改为 sync / auto decoding: async, }, }, ], }5.2 源码实现默认值定义在 packages/gatsby-remark-images/src/constants.jsDEFAULT_OPTIONS.decoding async与loading: lazy等默认项并列校验逻辑在 packages/gatsby-remark-images/src/index.js如果传入的不是async/sync/auto三者之一会通过 reporter 发出警告并把值写入生成的img标签见 index.js 中loading${loading} decoding${decoding}的模板插件级 schema 校验基于 Joi位于 packages/gatsby-remark-images/src/gatsby-node.js错误信息为decoding must be one of [async, sync, auto]对应的单元测试packages/gatsby-remark-images/src/tests/gatsby-node.js与快照tests/snapshots/index.js.snap均验证了decodingasync被正确输出。5.3 作用与取舍decoding属性控制浏览器是否允许并行化解码图片async默认允许浏览器在下载图片时并行解码通常更快显示sync要求图片按顺序解码在并行解码会引发问题如某些性能敏感的布局场景时使用用于禁用异步加载auto交给浏览器自行决定。该属性对应 HTML 标准中HTMLImageElement.decoding本仓库文档 docs/docs/reference/gatsby-remark-images.md 中亦有说明。六、Yarn 2PnP支持恢复Yarn 2 及其 PlugnPlayPnP模式在本版本重新可用。原因在于Gatsby v3 升级 webpack 4 → 5 的过程中一度破坏了 PnP 兼容性本次修复后重新恢复支持。为了确保未来不再回退仓库中新增了对应的e2e 测试。Yarn 2PnP带来的收益由于 Yarn 2 会激进地缓存node_modules通常可以体验到更快的npm install速度和更少的数据用量。七、值得关注的 Bugfix 与改进本版本还包含一批来自社区的质量修复发布说明中列出的主要内容如下gatsby核心自定义 webpack 配置时更好地检测 Babel rules修复 HMR 相关问题PR #31477svgo 插件配置修正PR #31620gatsby-plugin-gatsby-cloud修复Maximum call stack size exceeded报错PR #31547gatsby-source-contentful修复进度条闪烁问题PR #31467gatsby-source-wordpress阻止EADDRINUSE: address already in use 127.0.0.1错误PR #31710gatsby-remark-katex修复与 remark 13 的兼容性PR #31596。此外社区贡献者还修复了gatsby-source-wordpress中任何名为fields的字段的自动别名避免与 Gatsby 核心冲突、gatsby-source-contentful查询字符串中 crop 参数名错误、fast-refresh-overlay 的无限循环等若干问题。完整列表可参考 CHANGELOG.md。八、如何验证与试用体验新特性如果你希望尽早使用最新特性可以安装gatsbynext进行验证并在遇到问题时向官方仓库提交 issue本仓库根目录 SECURITY.md 中说明了安全问题的报告渠道。本地阅读源码本仓库即可直接查看上述全部实现Functions 内部插件packages/gatsby/src/internal-plugins/functions/gatsby-node.tswebpack 持久化缓存packages/gatsby/src/utils/webpack.config.jsNode Manifestpackages/gatsby/src/utils/node-manifest.ts、packages/gatsby/src/redux/actions/public.jsLMDB 数据存储packages/gatsby/src/datastore/lmdb/lmdb-datastore.ts图片 decodingpackages/gatsby-remark-images/src/index.js官方历史发布说明上一版本见 docs/docs/reference/release-notes/v3.6/index.md。总结gatsby3.7.0是一个「把实验转正 打基础」的版本Functions 结束实验期、webpack 持久化缓存开始灰度、Yarn 2 兼容性回归同时通过unstable_createNodeManifest和ownerNodeId为内容同步Content Sync/预览路由铺路用 LMDB 实验为超大站点的内存瓶颈探索解法并为图片渲染带来更细粒度的decoding控制。如果你正在升级 Gatsby v3 系列或在为源插件实现预览路由、为大型内容站点降低构建内存这个版本的特性值得重点关注。赞分享前端静态站点Web框架【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址https://gitcode.com/gh_mirrors/ga/gatsby点击查看免费下载相关推荐Gatsby v3.4.0 发布说明深度解析持久缓存、Serverless Functions 与聚合查询新能力Gatsby v3.4.0 发布说明深度解析持久缓存、Serverless Functions 与聚合查询新能力 导读 gatsby3.4.0 于 2021前端静态站点Web框架Gatsby v3.10 深入解析Parallel Query Running 与 webpack 持久缓存两大实验特性Gatsby v3.10 深入解析Parallel Query Running 与 webpack 持久缓存两大实验特性 Gatsby v3.10.0202前端静态站点Web框架Gatsby v3.8.0 版本发布详解React 18 Alpha 支持、Shopify v5 数据源、Web Vitals 跟踪与 webpack 持久化缓存Gatsby v3.8.0 版本发布详解React 18 Alpha 支持、Shopify v5 数据源、Web Vitals 跟踪与 webpack 持久化前端静态站点Web框架创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Gatsby v3.7 版本全解析：Serverless Functions 正式可用、webpack 持久化缓存灰度与 LMDB 节点持久化实验
前端静态站点Web框架【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址https://gitcode.com/gh_mirrors/ga/gatsby点击查看免费下载导读gatsby3.7.0于 2021 年 6 月 8 日发布June 2021 #1是 Gatsby v3 时代极具里程碑意义的一个版本Functions服务端函数正式 GA不再需要实验性 flagwebpack 5 内置持久化缓存开启 20% 用户灰度Yarn 2PnP支持恢复同时引入面向源插件的新公共 actionunstable_createNodeManifest用于把 CMS 内容状态与最终构建页面关联起来、实验性的 LMDB 节点持久化存储以及gatsby-remark-images的decoding图片解码属性。本文以官方发布说明为骨架结合当前仓库源码逐项展开帮助你理解每个特性的设计动机、使用方式与底层实现。一、Functions服务端函数正式 GA从本版本开始Gatsby Functions在src/api目录下编写、部署为无服务器函数的后端代码正式成为一级特性generally available。此前的实验阶段用户不再需要配置任何FUNCTIONS之类的 flag 即可使用。相关示例可参考仓库 examples 目录下functions-*系列示例如 functions-hello-world、functions-basic-form、functions-auth0 等。在实现层面Functions 的构建与开发支持位于 Gatsby 核心包的 packages/gatsby/src/internal-plugins/functions/gatsby-node.ts该内部插件负责在gatsby develop/gatsby build期间扫描、编译并托管这些函数。从源码可以看到开发阶段的编译行为还受环境变量控制process.env.GATSBY_PRECOMPILE_DEVELOP_FUNCTIONS true || process.env.GATSBY_PRECOMPILE_DEVELOP_FUNCTIONS 1即设置GATSBY_PRECOMPILE_DEVELOP_FUNCTIONStrue可让开发服务器预编译函数从而加快首次请求的响应速度。Functions 的完整使用文档位于 docs/docs/reference/functions/index.md。二、webpack 持久化缓存从 flag 到 20% 灰度webpack 5 引入了内置的持久化缓存persistent caching能力webpack 可以复用上一次编译的产物显著加快编译步骤。Gatsby 在 v3.4 版本中以 flag 形式接入该特性而本版本开始向全体用户渐进式灰度默认对 20% 的用户启用。从当前仓库的 packages/gatsby/src/utils/webpack.config.js 可以看到该特性的实际接入方式——在build-javascript、build-html、develop、develop-html这四个编译阶段中注入 filesystem 缓存配置const cacheLocation path.join( program.directory, .cache, webpack, stage- stage ) const cacheConfig { type: filesystem, name: stage, cacheLocation, buildDependencies: { config: [__filename, ...pluginsPaths], }, } config.cache cacheConfig几个关键点分阶段缓存每个编译阶段stage有独立的name与缓存目录.cache/webpack/stage-stage避免不同 stage 的产物互相污染构建依赖追踪buildDependencies.config显式列出 webpack 配置文件自身以及所有实现了onCreateWebpackConfig的插件路径。一旦这些文件发生变化缓存即失效重建保证配置变更不会被陈旧缓存掩盖缓存位置位于项目根目录.cache/webpack/下属于本地构建缓存的一部分可随.cache一起清理。由于仍处于灰度阶段如果你在使用中遇到编译异常官方建议在 umbrella discussion 中反馈并可通过配置/环境变量显式控制该特性的开关。三、新 APIunstable_createNodeManifest与ownerNodeId这是本版本对源插件source plugin生态最重要的一次 API 扩展通过把「CMS 中某个内容的唯一修订状态manifest ID」与「由某个节点构建出的最终页面」建立映射让外部服务如 CMS 的 Preview 服务在构建完成后把请求路由到正确的页面。3.1 公共 actionunstable_createNodeManifest本版本在 packages/gatsby/src/redux/actions/public.js 中新增了公共 actionunstable_createNodeManifest类型为CREATE_NODE_MANIFEST。其签名与参数如下actions.unstable_createNodeManifest({ manifestId: post-id-1--updated-53154315, updatedAtUTC: 2021-07-08T21:52:28.79101:00, node: { id: post-id-1, }, })参数说明来自源码 JSDoc参数必填说明manifestId是一个将 manifest 与数据源唯一修订状态关联起来的 ID如 CMS 内容的 id 修订版本号node是要关联的 Gatsby 节点对象参考createNodeaction 的节点格式核心是node.idupdatedAtUTC否节点最近一次更新的时间。若省略则对每次调用都生成 manifest默认只为最近 30 天内更新过的内容生成 manifest可通过环境变量NODE_MANIFEST_MAX_DAYS_OLD调整窗口注意由于 API 仍处于不稳定阶段名称保留了unstable_前缀说明其接口在后续版本中仍可能调整。3.2createPage新增ownerNodeId参数为了让「节点 → 页面」的映射更准确本版本给createPagehelper 增加了ownerNodeId参数允许你显式声明某个页面「归属于」某个节点。在 packages/gatsby/src/redux/actions/public.js 中可以看到页面内部对象会保存该字段internalPage.ownerNodeId page.ownerNodeIdJSDoc 中也特别强调ownerNodeId指向的节点必须确实在该页面的 GraphQL 查询中被用到multiple nodes can be queried on a single page, this allows the user to tell us which node is the main node for the page。因为一个页面可能查询多个节点这个参数用于消除歧义。3.3 页面查找逻辑的优先级当 manifest 被处理时核心逻辑位于 packages/gatsby/src/utils/node-manifest.ts 的findPageOwnedByNode。源码中定义了完整的查找优先级FoundPageBy类型ownerNodeId页面显式声明的ownerNodeId nodeId最精确、最推荐filesystem-route-api页面的context.id nodeId且页面由gatsby-plugin-page-creator文件系统路由 API创建context.id页面 context 中存在与节点 id 匹配的id变量context.slug页面 context 中存在与节点slug匹配的slug变量queryTracking都没有时回退到查询追踪query tracking里第一个使用到该节点的页面none最终找不到页面。源码注释解释了兜底顺序的设计原因用id/slug作为 GraphQL 查询变量是常见写法因此即使没指定 owner也能作为比「随便抓第一个查询到该节点的页面」更好的猜测而queryTracking是最后手段。3.4 处理流程与产物processNodeManifests同样在 node-manifest.ts会统一处理待处理的 manifests使用fastq 并发队列并发数 25逐个处理避免大量 manifest 时发生栈溢出源码中特意用setImmediate规避受NODE_MANIFEST_FILE_LIMIT限制默认 10000可通过同名环境变量覆盖超限时按updatedAtUTC升序排序后只保留最早的部分优先写出每个 manifest 最终以 JSON 文件形式写入public/__node-manifests/pluginName/manifestId.jsonWindows 下会对:/\*?|\\等保留字符做替换以避免文件名非法见源码中对process.platform win32的分支处理处理结束后从 store 中清空待处理列表并在控制台输出统计信息如Wrote out N node page manifest file(s) in X ms若映射失败如找不到节点11804、找不到页面11801等会按错误 ID 汇总告警设置VERBOSE_NODE_MANIFESTtrue或gatsby_log_levelverbose可查看完整告警信息。最终效果正如发布说明所述源插件可以让 CMS 用一个 CMS ID 生成 manifest 文件该文件映射到 Gatsby 中最终构建完成的页面从而让外部服务在构建结束后把用户重定向到正确的页面如内容预览。四、实验特性LMDB 节点持久化存储本版本引入了一个实验性的数据存储选项LMDB通过lmdb/lmdb-store包实现。此前 Gatsby 的所有节点都保存在内存中的 Redux store 里遇到超大型站点时把 redux 状态持久化到磁盘可能导致OOM内存溢出。改用 LMDB 后节点被即时保存到这种持久化嵌入式存储中从而显著降低峰值内存占用并为此后的更多性能优化铺路。在当前仓库中该实验的实现位于 packages/gatsby/src/datastore/lmdb/lmdb-datastore.ts它基于lmdb包封装了数据存储层。从源码结构可以推断启用开关与环境变量相关if (process.env.GATSBY_EXPERIMENTAL_LMDB_INDEXES) { // 实验性的 LMDB 索引支持 }也就是说GATSBY_EXPERIMENTAL_LMDB_INDEXES控制的是 LMDB 索引层面的实验能力而整体启用 LMDB 存储的实验安装步骤以 Umbrella Discussion 中的说明为准。作为实验特性它仅推荐给希望降低大站点构建内存峰值的用户尝试并欢迎反馈问题。相关测试与查询支持代码位于 packages/gatsby/src/datastore/lmdb/query/包含基于索引的过滤查询、索引建议等可进一步了解其能力边界。五、gatsby-remark-images默认启用异步图片解码本版本为gatsby-remark-images插件新增了decoding选项用于给插件产出的所有img标签添加对应的decoding属性默认值为async允许的取值为async、sync、auto。5.1 配置方式在gatsby-config.js中配置插件即可module.exports { plugins: [ { resolve: gatsby-remark-images, options: { // 默认值即 async按需改为 sync / auto decoding: async, }, }, ], }5.2 源码实现默认值定义在 packages/gatsby-remark-images/src/constants.jsDEFAULT_OPTIONS.decoding async与loading: lazy等默认项并列校验逻辑在 packages/gatsby-remark-images/src/index.js如果传入的不是async/sync/auto三者之一会通过 reporter 发出警告并把值写入生成的img标签见 index.js 中loading${loading} decoding${decoding}的模板插件级 schema 校验基于 Joi位于 packages/gatsby-remark-images/src/gatsby-node.js错误信息为decoding must be one of [async, sync, auto]对应的单元测试packages/gatsby-remark-images/src/tests/gatsby-node.js与快照tests/snapshots/index.js.snap均验证了decodingasync被正确输出。5.3 作用与取舍decoding属性控制浏览器是否允许并行化解码图片async默认允许浏览器在下载图片时并行解码通常更快显示sync要求图片按顺序解码在并行解码会引发问题如某些性能敏感的布局场景时使用用于禁用异步加载auto交给浏览器自行决定。该属性对应 HTML 标准中HTMLImageElement.decoding本仓库文档 docs/docs/reference/gatsby-remark-images.md 中亦有说明。六、Yarn 2PnP支持恢复Yarn 2 及其 PlugnPlayPnP模式在本版本重新可用。原因在于Gatsby v3 升级 webpack 4 → 5 的过程中一度破坏了 PnP 兼容性本次修复后重新恢复支持。为了确保未来不再回退仓库中新增了对应的e2e 测试。Yarn 2PnP带来的收益由于 Yarn 2 会激进地缓存node_modules通常可以体验到更快的npm install速度和更少的数据用量。七、值得关注的 Bugfix 与改进本版本还包含一批来自社区的质量修复发布说明中列出的主要内容如下gatsby核心自定义 webpack 配置时更好地检测 Babel rules修复 HMR 相关问题PR #31477svgo 插件配置修正PR #31620gatsby-plugin-gatsby-cloud修复Maximum call stack size exceeded报错PR #31547gatsby-source-contentful修复进度条闪烁问题PR #31467gatsby-source-wordpress阻止EADDRINUSE: address already in use 127.0.0.1错误PR #31710gatsby-remark-katex修复与 remark 13 的兼容性PR #31596。此外社区贡献者还修复了gatsby-source-wordpress中任何名为fields的字段的自动别名避免与 Gatsby 核心冲突、gatsby-source-contentful查询字符串中 crop 参数名错误、fast-refresh-overlay 的无限循环等若干问题。完整列表可参考 CHANGELOG.md。八、如何验证与试用体验新特性如果你希望尽早使用最新特性可以安装gatsbynext进行验证并在遇到问题时向官方仓库提交 issue本仓库根目录 SECURITY.md 中说明了安全问题的报告渠道。本地阅读源码本仓库即可直接查看上述全部实现Functions 内部插件packages/gatsby/src/internal-plugins/functions/gatsby-node.tswebpack 持久化缓存packages/gatsby/src/utils/webpack.config.jsNode Manifestpackages/gatsby/src/utils/node-manifest.ts、packages/gatsby/src/redux/actions/public.jsLMDB 数据存储packages/gatsby/src/datastore/lmdb/lmdb-datastore.ts图片 decodingpackages/gatsby-remark-images/src/index.js官方历史发布说明上一版本见 docs/docs/reference/release-notes/v3.6/index.md。总结gatsby3.7.0是一个「把实验转正 打基础」的版本Functions 结束实验期、webpack 持久化缓存开始灰度、Yarn 2 兼容性回归同时通过unstable_createNodeManifest和ownerNodeId为内容同步Content Sync/预览路由铺路用 LMDB 实验为超大站点的内存瓶颈探索解法并为图片渲染带来更细粒度的decoding控制。如果你正在升级 Gatsby v3 系列或在为源插件实现预览路由、为大型内容站点降低构建内存这个版本的特性值得重点关注。赞分享前端静态站点Web框架【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址https://gitcode.com/gh_mirrors/ga/gatsby点击查看免费下载相关推荐Gatsby v3.4.0 发布说明深度解析持久缓存、Serverless Functions 与聚合查询新能力Gatsby v3.4.0 发布说明深度解析持久缓存、Serverless Functions 与聚合查询新能力 导读 gatsby3.4.0 于 2021前端静态站点Web框架Gatsby v3.10 深入解析Parallel Query Running 与 webpack 持久缓存两大实验特性Gatsby v3.10 深入解析Parallel Query Running 与 webpack 持久缓存两大实验特性 Gatsby v3.10.0202前端静态站点Web框架Gatsby v3.8.0 版本发布详解React 18 Alpha 支持、Shopify v5 数据源、Web Vitals 跟踪与 webpack 持久化缓存Gatsby v3.8.0 版本发布详解React 18 Alpha 支持、Shopify v5 数据源、Web Vitals 跟踪与 webpack 持久化前端静态站点Web框架创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考