前端静态站点Web框架【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址https://gitcode.com/gh_mirrors/ga/gatsby点击查看免费下载导读本文基于 Gatsby 官方项目结构文档系统梳理一个 Gatsby 站点从根目录到src、从gatsby-config.js到gatsby-ssr.js的完整文件骨架并结合本仓库中的真实 starter 示例与packages/gatsby源码解释每个目录与文件的职责、生成机制与底层原理。读完本文你将能准确判断一个 Gatsby 项目中每个文件该放什么、不该放什么并能独立搭建、配置与扩展一个结构规范的 Gatsby 站点。一、总览一个典型 Gatsby 项目的完整骨架在原文档中一个 Gatsby 项目可能包含以下部分或全部文件夹与文件/ |-- /.cache |-- /plugins |-- /public |-- /src |-- /api |-- /pages |-- /templates |-- html.js |-- /static |-- gatsby-config.js |-- gatsby-node.js |-- gatsby-ssr.js |-- gatsby-browser.js其中/.cache与/public是自动生成的目录不应手动修改其余目录与文件是开发者编写或配置的源码部分。下面分别深入讲解。本仓库中 starters/default 与 starters/gatsby-starter-minimal 是两个可直接对照的真实示例gatsby-starter-minimal只保留了最精简的gatsby-config.js、src/pages与静态图标而defaultstarter 则几乎覆盖了上图中除plugins、static之外的全部结构非常适合作为学习参照物。二、文件夹详解2.1/.cache—— 自动生成的内部缓存/.cache是 Gatsby 自动创建的内部缓存目录存放构建与开发过程中的临时产物包括编译后的函数、webpack 状态、页面数据等。该目录中的文件不面向开发者修改且应当被加入.gitignore如尚未加入的话。从源码看该目录承担了大量实际工作。例如 Gatsby Functions 在开发模式下会被编译到.cache下在 packages/gatsby/src/internal-plugins/functions/gatsby-node.ts 中每个函数都包含absoluteCompiledFilePath指向.cache/functions/...下编译产物与originalAbsoluteFilePath指向src/api/...原始文件两类路径开发模式下函数采用按需惰性编译——只有被请求时才编译文件头部注释明确写着 During development, we lazily compile functions only when theyre requested编译产物即落在.cache中。此外packages/gatsby/cache-dir/下的static-entry.js、develop-static-entry.js等也是由.cache机制承载的核心运行时入口。2.2/plugins—— 站点本地插件/plugins目录用于存放仅针对当前站点的本地插件local plugins即未发布为npm包的插件。本地插件与 npm 安装的插件在能力上没有差别——都可以实现onCreateNode、createPages等 Gatsby Node API 或提供src/api函数——区别仅在于分发方式。本仓库的 starters/gatsby-starter-plugin 就是一个完整的本地插件 starter它展示了插件应有的最小骨架index.js插件主入口、gatsby-browser.js、gatsby-node.js、gatsby-ssr.js与package.json。关于插件 API 的更多细节可参见仓库中的插件示例与 creating-a-local-plugin 指南。2.3/public—— 构建产物输出目录/public是构建过程的输出目录gatsby build生成的静态站点文件HTML、JS、CSS、静态资源都会暴露在此目录中。该目录同样应加入.gitignore。在 webpack 配置层面packages/gatsby/src/utils/webpack.config.js 中明确将编译输出路径指向public目录path: directoryPath(\public)并设置envObject.PUBLIC_DIR JSON.stringify(${process.cwd()}/public)这印证了/public作为最终产物目录的地位。日常开发中你通常不会直接操作该目录而是通过gatsby build/gatsby serve 生成并预览其中的结果。2.4/src—— 前端源码主目录/src存放与站点**前端展示浏览器中看到的内容**相关的全部代码例如站点头部组件或页面模板。src 是 source code源代码的约定缩写。它内部通常包含以下子目录与文件/api—— 自动成为函数的目录src/api下的 JavaScript 与 TypeScript 文件会自动成为函数Functions其路径由文件名决定。例如 examples/functions-hello-world/src/api/hello-world.js 导出一个接收(req, res)的处理器const sample (req, res) { res.status(200).json({ message: Hello, World! }) } export default sample该文件部署后即对应一个hello-world路径的函数接口返回 JSON 响应。从实现层面看函数目录的扫描逻辑位于 packages/gatsby/src/internal-plugins/functions/gatsby-node.ts它以 glob 模式siteDirectoryPath/src/api/**/*.{js,ts}匹配所有 JS/TS 文件并自动排除__tests__、*.spec.*、*.test.*与*.d.ts文件详见globIgnorePatterns函数。也就是说测试文件放在src/api下不会被误注册为线上函数。此外函数还可以通过导出config对象配置bodyParser等行为其校验逻辑参见 packages/gatsby/src/internal-plugins/functions/tests/config.ts。/pages—— 自动生成页面的目录src/pages下的组件会自动成为页面路由由文件名决定。例如src/pages/index.js对应站点首页src/pages/about.js对应/about。这是 Gatsby 基于文件系统file-system routing的核心约定。可参考 starters/default/src/pages/index.js 与 starters/default/src/pages/404.js自动生成 404 页面的写法。/templates—— 程序化建页的模板/templates存放用于程序化创建页面的模板组件。与src/pages的自动路由不同模板本身不会自动生成页面而是由gatsby-node.js中的createPagesAPI 配合数据查询批量实例化。原文档将其称为 page template components。仓库中 starters/default/src/templates/using-dsg.js 是一个典型的模板组件它接收页面数据作为 props 渲染布局与内容并通过export const Head输出页面级 SEO 元数据。而对应的程序化建页逻辑在 starters/default/gatsby-node.js 中见下文 3.3 节。html.js—— 自定义默认 HTML 模板src/html.js用于自定义默认的.cache/default_html.js即 Gatsby 默认生成的 HTML 文档外壳。当你需要精确控制html、body的标签结构或注入自定义脚本、样式时可以在src下创建html.js覆盖默认实现。其底层机制在 packages/gatsby/cache-dir/static-entry.js 中有直接体现渲染 HTML 时先尝试require(../src/html)若该文件不存在抛出testRequireError则回退到内置的./default-html。这从源码层面印证了src/html.js与默认 HTML 模板之间的覆盖关系。2.5/static—— 原样拷贝的静态资源放进/static目录的文件不会经过 webpack 处理而是被原样复制到/public目录。这意味着适合放置无需处理的资源favicon、robots.txt、外部引用的图片等引用方式与站点根路径一致如/static下的logo.png通过/logo.png访问或配合pathPrefix处理与src下的资源可被 webpack 处理、支持优化与指纹化形成互补。这是模块系统之外添加资源的标准做法也是starters中普遍保留 favicon如static/favicon.ico的原因。三、配置文件详解原文档指出以下四个文件均支持以 TypeScript 编写详见 TypeScript 配置指南下面以 JS 形式讲解其职责。3.1gatsby-config.js—— 站点主配置gatsby-config.js是 Gatsby 站点的主配置文件用于声明站点元数据siteMetadata如站点标题、描述与要启用的 Gatsby 插件列表等。最精简的配置只需一个空对象starters/hello-world/gatsby-config.js 即是范例/** * type {import(gatsby).GatsbyConfig} */ module.exports { plugins: [], }而 starters/default/gatsby-config.js 展示了一个带元数据与插件体系的完整配置module.exports { siteMetadata: { title: Gatsby Default Starter, description: Kick off your next, great Gatsby project with this default starter., author: gatsbyjs, siteUrl: https://gatsbystarterdefaultsource.gatsbyjs.io/, }, plugins: [ gatsby-plugin-image, { resolve: gatsby-source-filesystem, options: { name: images, path: ${__dirname}/src/images, }, }, gatsby-transformer-sharp, gatsby-plugin-sharp, { resolve: gatsby-plugin-manifest, options: { name: gatsby-starter-default, short_name: starter, start_url: /, background_color: #663399, display: minimal-ui, icon: src/images/gatsby-icon.png, }, }, ], }从中可以提炼出三条实用规则纯字符串插件如gatsby-plugin-image无需配置直接列出即可需要传参的插件使用{ resolve, options }对象形式options内是插件专属配置项siteMetadata中的数据可在站点任意位置的 GraphQL 查询如site { siteMetadata { title } }中直接访问是全局站点信息的事实标准存放处。3.2gatsby-browser.js—— 浏览器端 APIgatsby-browser.js用于实现 Gatsby 浏览器 API如有需要这些 API 允许你自定义/扩展影响浏览器的默认行为例如onClientEntry客户端进入时执行、registerServiceWorker、shouldUpdateScroll、wrapRootElement等。该文件不是必需的——starters/default/gatsby-browser.js 中甚至只有一句注释// You can delete this file if youre not using it如果你没有使用它可以删除该文件。3.3gatsby-node.js—— 构建期 Node APIgatsby-node.js用于实现 Gatsby Node API如有需要这些 API 允许自定义/扩展影响站点构建过程的默认设置例如onCreateNode节点创建时、createSchemaCustomization自定义 schema、createPages程序化建页等。仓库中的 starters/default/gatsby-node.js 是一个调用createPages创建按需静态生成DSG页面的完整示例/** * type {import(gatsby).GatsbyNode[createPages]} */ exports.createPages async ({ actions }) { const { createPage } actions createPage({ path: /using-dsg, component: require.resolve(./src/templates/using-dsg.js), context: {}, defer: true, }) }这里的三个要点path最终页面的访问路径component用于渲染该页面的模板组件对应src/templates目录context向模板传递的数据上下文可与 GraphQL 页面查询参数联动defer: true启用 Deferred Static Generation页面按需构建——对应 starters/default/src/templates/using-dsg.js 中 This page is not created until requested by a user 的描述。更复杂的程序化建页如从 Markdown/数据源批量生成博客文章可参考 docs/docs/programmatically-create-pages-from-data.md 与仓库中的 benchmarks/gabe-fs-markdown 等示例。3.4gatsby-ssr.js—— 服务端渲染 APIgatsby-ssr.js用于实现 Gatsby 服务端渲染 API如有需要这些 API 允许自定义影响**服务端渲染SSR**阶段的默认设置例如onRenderBody在渲染body时执行、onPreRenderHTML、replaceRenderer等。starters/default/gatsby-ssr.js 给出了一个最常见的用法——为html标签设置语言属性/** * type {import(gatsby).GatsbySSR[onRenderBody]} */ exports.onRenderBody ({ setHtmlAttributes }) { setHtmlAttributes({ lang: en }) }通过setHtmlAttributes可以在 SSR 阶段把langen注入最终 HTML 的html元素这对 SEO 与无障碍访问都有实际意义。四、TypeScript 支持原文档明确指出上述所有配置文件均可使用 TypeScript 编写。你可以将gatsby-config.js替换为gatsby-config.ts将gatsby-node.js替换为gatsby-node.ts以此类推。仓库本身即大量采用 TS 实现例如 packages/gatsby/src/internal-plugins/functions/gatsby-node.ts 就是以 TypeScript 编写的 Node API 实现而类型标注写法如import(gatsby).GatsbyConfig、import(gatsby).GatsbyNode[createPages]可直接从.js文件中获得完整的编辑器智能提示这是 JS 项目向 TS 平滑迁移的推荐路径。更多细节参见 TypeScript 配置指南 与仓库中的 examples/using-typescript 示例。五、杂项在 Gatsby 中使用标准 React 组织模式上述文件/文件夹结构反映的是Gatsby 特有的部分。由于 Gatsby 站点本质上就是 React 应用因此完全可以而且推荐采用标准的 React 代码组织模式例如在src内建立/components与/utils等目录。这一点在仓库的 starter 中有大量体现starters/default/src 就包含components/header.js、layout.js、seo.js、images/、pages/、templates/的经典分层examples/route-api/src 则使用pages/与views/区分页面入口与视图组件。整体上推荐的实践是把可复用 UI 组件放入src/components把路由页面放入src/pages把程序化建页模板放入src/templates把工具函数、hooks等放入src/utils或独立目录站点级配置与全局信息放入gatsby-config.js的siteMetadata。六、小结一份可对照的检查清单路径是否手写核心职责/.cache自动生成内部缓存与构建中间产物勿手动修改加入.gitignore/plugins手写站点本地插件/public自动生成构建产物输出目录加入.gitignore/src/pages手写按文件名自动生成路由页面/src/templates手写供createPages程序化建页的模板/src/api手写按文件名自动生成函数Functions/src/html.js可选覆盖默认.cache/default_html.js的 HTML 外壳/static手写不经 webpack、原样拷贝到/publicgatsby-config.js手写站点元数据与插件配置gatsby-browser.js可选浏览器端 APIgatsby-node.js可选构建期 Node APIgatsby-ssr.js可选服务端渲染 API理解这份结构是正确使用 Gatsby 各项能力页面路由、数据查询、Functions、插件体系、SSR/DSG 渲染策略的前提。对照本仓库 starters/gatsby-starter-minimal最精简、starters/default完整与 starters/gatsby-starter-plugin插件形态三套模板即可快速掌握从零搭建到深度定制的完整路径。赞分享前端静态站点Web框架【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址https://gitcode.com/gh_mirrors/ga/gatsby点击查看免费下载相关推荐searchGPT革命性开源LLM搜索引擎诞生彻底改变你的信息获取方式searchGPT革命性开源LLM搜索引擎诞生彻底改变你的信息获取方式 searchGPT是一款基于LLM/ChatGPT/OpenAI API构建的革命性Gatsby 默认 Starter 项目结构与配置文件完全指南基于 development-runtime 目录的实战解读Gatsby 默认 Starter 项目结构与配置文件完全指南基于 development runtime 目录的实战解读 本指南以仓库中 e2e tests前端静态站点Web框架Backstage 插件结构详解从目录骨架到扩展接入的完整实战指南Backstage 插件结构详解从目录骨架到扩展接入的完整实战指南 本篇技术指南聚焦 Backstage 前端插件的标准目录结构与组成要素以官方 struc开发者门户后端前端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Gatsby 项目结构完全指南：从目录骨架到配置文件实战解析
前端静态站点Web框架【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址https://gitcode.com/gh_mirrors/ga/gatsby点击查看免费下载导读本文基于 Gatsby 官方项目结构文档系统梳理一个 Gatsby 站点从根目录到src、从gatsby-config.js到gatsby-ssr.js的完整文件骨架并结合本仓库中的真实 starter 示例与packages/gatsby源码解释每个目录与文件的职责、生成机制与底层原理。读完本文你将能准确判断一个 Gatsby 项目中每个文件该放什么、不该放什么并能独立搭建、配置与扩展一个结构规范的 Gatsby 站点。一、总览一个典型 Gatsby 项目的完整骨架在原文档中一个 Gatsby 项目可能包含以下部分或全部文件夹与文件/ |-- /.cache |-- /plugins |-- /public |-- /src |-- /api |-- /pages |-- /templates |-- html.js |-- /static |-- gatsby-config.js |-- gatsby-node.js |-- gatsby-ssr.js |-- gatsby-browser.js其中/.cache与/public是自动生成的目录不应手动修改其余目录与文件是开发者编写或配置的源码部分。下面分别深入讲解。本仓库中 starters/default 与 starters/gatsby-starter-minimal 是两个可直接对照的真实示例gatsby-starter-minimal只保留了最精简的gatsby-config.js、src/pages与静态图标而defaultstarter 则几乎覆盖了上图中除plugins、static之外的全部结构非常适合作为学习参照物。二、文件夹详解2.1/.cache—— 自动生成的内部缓存/.cache是 Gatsby 自动创建的内部缓存目录存放构建与开发过程中的临时产物包括编译后的函数、webpack 状态、页面数据等。该目录中的文件不面向开发者修改且应当被加入.gitignore如尚未加入的话。从源码看该目录承担了大量实际工作。例如 Gatsby Functions 在开发模式下会被编译到.cache下在 packages/gatsby/src/internal-plugins/functions/gatsby-node.ts 中每个函数都包含absoluteCompiledFilePath指向.cache/functions/...下编译产物与originalAbsoluteFilePath指向src/api/...原始文件两类路径开发模式下函数采用按需惰性编译——只有被请求时才编译文件头部注释明确写着 During development, we lazily compile functions only when theyre requested编译产物即落在.cache中。此外packages/gatsby/cache-dir/下的static-entry.js、develop-static-entry.js等也是由.cache机制承载的核心运行时入口。2.2/plugins—— 站点本地插件/plugins目录用于存放仅针对当前站点的本地插件local plugins即未发布为npm包的插件。本地插件与 npm 安装的插件在能力上没有差别——都可以实现onCreateNode、createPages等 Gatsby Node API 或提供src/api函数——区别仅在于分发方式。本仓库的 starters/gatsby-starter-plugin 就是一个完整的本地插件 starter它展示了插件应有的最小骨架index.js插件主入口、gatsby-browser.js、gatsby-node.js、gatsby-ssr.js与package.json。关于插件 API 的更多细节可参见仓库中的插件示例与 creating-a-local-plugin 指南。2.3/public—— 构建产物输出目录/public是构建过程的输出目录gatsby build生成的静态站点文件HTML、JS、CSS、静态资源都会暴露在此目录中。该目录同样应加入.gitignore。在 webpack 配置层面packages/gatsby/src/utils/webpack.config.js 中明确将编译输出路径指向public目录path: directoryPath(\public)并设置envObject.PUBLIC_DIR JSON.stringify(${process.cwd()}/public)这印证了/public作为最终产物目录的地位。日常开发中你通常不会直接操作该目录而是通过gatsby build/gatsby serve 生成并预览其中的结果。2.4/src—— 前端源码主目录/src存放与站点**前端展示浏览器中看到的内容**相关的全部代码例如站点头部组件或页面模板。src 是 source code源代码的约定缩写。它内部通常包含以下子目录与文件/api—— 自动成为函数的目录src/api下的 JavaScript 与 TypeScript 文件会自动成为函数Functions其路径由文件名决定。例如 examples/functions-hello-world/src/api/hello-world.js 导出一个接收(req, res)的处理器const sample (req, res) { res.status(200).json({ message: Hello, World! }) } export default sample该文件部署后即对应一个hello-world路径的函数接口返回 JSON 响应。从实现层面看函数目录的扫描逻辑位于 packages/gatsby/src/internal-plugins/functions/gatsby-node.ts它以 glob 模式siteDirectoryPath/src/api/**/*.{js,ts}匹配所有 JS/TS 文件并自动排除__tests__、*.spec.*、*.test.*与*.d.ts文件详见globIgnorePatterns函数。也就是说测试文件放在src/api下不会被误注册为线上函数。此外函数还可以通过导出config对象配置bodyParser等行为其校验逻辑参见 packages/gatsby/src/internal-plugins/functions/tests/config.ts。/pages—— 自动生成页面的目录src/pages下的组件会自动成为页面路由由文件名决定。例如src/pages/index.js对应站点首页src/pages/about.js对应/about。这是 Gatsby 基于文件系统file-system routing的核心约定。可参考 starters/default/src/pages/index.js 与 starters/default/src/pages/404.js自动生成 404 页面的写法。/templates—— 程序化建页的模板/templates存放用于程序化创建页面的模板组件。与src/pages的自动路由不同模板本身不会自动生成页面而是由gatsby-node.js中的createPagesAPI 配合数据查询批量实例化。原文档将其称为 page template components。仓库中 starters/default/src/templates/using-dsg.js 是一个典型的模板组件它接收页面数据作为 props 渲染布局与内容并通过export const Head输出页面级 SEO 元数据。而对应的程序化建页逻辑在 starters/default/gatsby-node.js 中见下文 3.3 节。html.js—— 自定义默认 HTML 模板src/html.js用于自定义默认的.cache/default_html.js即 Gatsby 默认生成的 HTML 文档外壳。当你需要精确控制html、body的标签结构或注入自定义脚本、样式时可以在src下创建html.js覆盖默认实现。其底层机制在 packages/gatsby/cache-dir/static-entry.js 中有直接体现渲染 HTML 时先尝试require(../src/html)若该文件不存在抛出testRequireError则回退到内置的./default-html。这从源码层面印证了src/html.js与默认 HTML 模板之间的覆盖关系。2.5/static—— 原样拷贝的静态资源放进/static目录的文件不会经过 webpack 处理而是被原样复制到/public目录。这意味着适合放置无需处理的资源favicon、robots.txt、外部引用的图片等引用方式与站点根路径一致如/static下的logo.png通过/logo.png访问或配合pathPrefix处理与src下的资源可被 webpack 处理、支持优化与指纹化形成互补。这是模块系统之外添加资源的标准做法也是starters中普遍保留 favicon如static/favicon.ico的原因。三、配置文件详解原文档指出以下四个文件均支持以 TypeScript 编写详见 TypeScript 配置指南下面以 JS 形式讲解其职责。3.1gatsby-config.js—— 站点主配置gatsby-config.js是 Gatsby 站点的主配置文件用于声明站点元数据siteMetadata如站点标题、描述与要启用的 Gatsby 插件列表等。最精简的配置只需一个空对象starters/hello-world/gatsby-config.js 即是范例/** * type {import(gatsby).GatsbyConfig} */ module.exports { plugins: [], }而 starters/default/gatsby-config.js 展示了一个带元数据与插件体系的完整配置module.exports { siteMetadata: { title: Gatsby Default Starter, description: Kick off your next, great Gatsby project with this default starter., author: gatsbyjs, siteUrl: https://gatsbystarterdefaultsource.gatsbyjs.io/, }, plugins: [ gatsby-plugin-image, { resolve: gatsby-source-filesystem, options: { name: images, path: ${__dirname}/src/images, }, }, gatsby-transformer-sharp, gatsby-plugin-sharp, { resolve: gatsby-plugin-manifest, options: { name: gatsby-starter-default, short_name: starter, start_url: /, background_color: #663399, display: minimal-ui, icon: src/images/gatsby-icon.png, }, }, ], }从中可以提炼出三条实用规则纯字符串插件如gatsby-plugin-image无需配置直接列出即可需要传参的插件使用{ resolve, options }对象形式options内是插件专属配置项siteMetadata中的数据可在站点任意位置的 GraphQL 查询如site { siteMetadata { title } }中直接访问是全局站点信息的事实标准存放处。3.2gatsby-browser.js—— 浏览器端 APIgatsby-browser.js用于实现 Gatsby 浏览器 API如有需要这些 API 允许你自定义/扩展影响浏览器的默认行为例如onClientEntry客户端进入时执行、registerServiceWorker、shouldUpdateScroll、wrapRootElement等。该文件不是必需的——starters/default/gatsby-browser.js 中甚至只有一句注释// You can delete this file if youre not using it如果你没有使用它可以删除该文件。3.3gatsby-node.js—— 构建期 Node APIgatsby-node.js用于实现 Gatsby Node API如有需要这些 API 允许自定义/扩展影响站点构建过程的默认设置例如onCreateNode节点创建时、createSchemaCustomization自定义 schema、createPages程序化建页等。仓库中的 starters/default/gatsby-node.js 是一个调用createPages创建按需静态生成DSG页面的完整示例/** * type {import(gatsby).GatsbyNode[createPages]} */ exports.createPages async ({ actions }) { const { createPage } actions createPage({ path: /using-dsg, component: require.resolve(./src/templates/using-dsg.js), context: {}, defer: true, }) }这里的三个要点path最终页面的访问路径component用于渲染该页面的模板组件对应src/templates目录context向模板传递的数据上下文可与 GraphQL 页面查询参数联动defer: true启用 Deferred Static Generation页面按需构建——对应 starters/default/src/templates/using-dsg.js 中 This page is not created until requested by a user 的描述。更复杂的程序化建页如从 Markdown/数据源批量生成博客文章可参考 docs/docs/programmatically-create-pages-from-data.md 与仓库中的 benchmarks/gabe-fs-markdown 等示例。3.4gatsby-ssr.js—— 服务端渲染 APIgatsby-ssr.js用于实现 Gatsby 服务端渲染 API如有需要这些 API 允许自定义影响**服务端渲染SSR**阶段的默认设置例如onRenderBody在渲染body时执行、onPreRenderHTML、replaceRenderer等。starters/default/gatsby-ssr.js 给出了一个最常见的用法——为html标签设置语言属性/** * type {import(gatsby).GatsbySSR[onRenderBody]} */ exports.onRenderBody ({ setHtmlAttributes }) { setHtmlAttributes({ lang: en }) }通过setHtmlAttributes可以在 SSR 阶段把langen注入最终 HTML 的html元素这对 SEO 与无障碍访问都有实际意义。四、TypeScript 支持原文档明确指出上述所有配置文件均可使用 TypeScript 编写。你可以将gatsby-config.js替换为gatsby-config.ts将gatsby-node.js替换为gatsby-node.ts以此类推。仓库本身即大量采用 TS 实现例如 packages/gatsby/src/internal-plugins/functions/gatsby-node.ts 就是以 TypeScript 编写的 Node API 实现而类型标注写法如import(gatsby).GatsbyConfig、import(gatsby).GatsbyNode[createPages]可直接从.js文件中获得完整的编辑器智能提示这是 JS 项目向 TS 平滑迁移的推荐路径。更多细节参见 TypeScript 配置指南 与仓库中的 examples/using-typescript 示例。五、杂项在 Gatsby 中使用标准 React 组织模式上述文件/文件夹结构反映的是Gatsby 特有的部分。由于 Gatsby 站点本质上就是 React 应用因此完全可以而且推荐采用标准的 React 代码组织模式例如在src内建立/components与/utils等目录。这一点在仓库的 starter 中有大量体现starters/default/src 就包含components/header.js、layout.js、seo.js、images/、pages/、templates/的经典分层examples/route-api/src 则使用pages/与views/区分页面入口与视图组件。整体上推荐的实践是把可复用 UI 组件放入src/components把路由页面放入src/pages把程序化建页模板放入src/templates把工具函数、hooks等放入src/utils或独立目录站点级配置与全局信息放入gatsby-config.js的siteMetadata。六、小结一份可对照的检查清单路径是否手写核心职责/.cache自动生成内部缓存与构建中间产物勿手动修改加入.gitignore/plugins手写站点本地插件/public自动生成构建产物输出目录加入.gitignore/src/pages手写按文件名自动生成路由页面/src/templates手写供createPages程序化建页的模板/src/api手写按文件名自动生成函数Functions/src/html.js可选覆盖默认.cache/default_html.js的 HTML 外壳/static手写不经 webpack、原样拷贝到/publicgatsby-config.js手写站点元数据与插件配置gatsby-browser.js可选浏览器端 APIgatsby-node.js可选构建期 Node APIgatsby-ssr.js可选服务端渲染 API理解这份结构是正确使用 Gatsby 各项能力页面路由、数据查询、Functions、插件体系、SSR/DSG 渲染策略的前提。对照本仓库 starters/gatsby-starter-minimal最精简、starters/default完整与 starters/gatsby-starter-plugin插件形态三套模板即可快速掌握从零搭建到深度定制的完整路径。赞分享前端静态站点Web框架【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址https://gitcode.com/gh_mirrors/ga/gatsby点击查看免费下载相关推荐searchGPT革命性开源LLM搜索引擎诞生彻底改变你的信息获取方式searchGPT革命性开源LLM搜索引擎诞生彻底改变你的信息获取方式 searchGPT是一款基于LLM/ChatGPT/OpenAI API构建的革命性Gatsby 默认 Starter 项目结构与配置文件完全指南基于 development-runtime 目录的实战解读Gatsby 默认 Starter 项目结构与配置文件完全指南基于 development runtime 目录的实战解读 本指南以仓库中 e2e tests前端静态站点Web框架Backstage 插件结构详解从目录骨架到扩展接入的完整实战指南Backstage 插件结构详解从目录骨架到扩展接入的完整实战指南 本篇技术指南聚焦 Backstage 前端插件的标准目录结构与组成要素以官方 struc开发者门户后端前端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考