Vite create-vite 的 Svelte TypeScript 模板解析svelte-ts 技术选型与配置实现【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite本篇技术文章围绕 Vite 仓库中packages/create-vite提供的 Svelte TypeScript 模板svelte-ts展开。读完你将理解该模板的定位与适用场景、相对 SvelteKit 的取舍原因并掌握其 TypeScript 工程化配置project references、types、allowJs/checkJs、Vite 构建链路、Svelte 5 入口挂载方式以及 HMR 状态保持的已知限制与外部 store 规避方案。模板定位create-vite 中的 svelte-ts 变体create-vite是 Vite 官方的项目脚手架工具在 Svelte 技术栈下提供三个变体。从 create-vite 入口源码 中可以看到其定义{ name: svelte, display: Svelte, color: red, variants: [ { name: svelte-ts, display: TypeScript, color: blue }, { name: svelte, display: JavaScript, color: yellow }, { name: custom-svelte-kit, display: SvelteKit ↗, customCommand: npm exec sv create TARGET_DIR, }, ], },即选择 Svelte TypeScript 时会使用本模板模板目录而 SvelteKit 变体实际上是把命令委托给sv create并不走 create-vite 的本地模板复制流程。本地模板目录的完整结构如下内容刻意保持最小化template-svelte-ts/ ├── .vscode/ │ └── extensions.json # VS Code 扩展推荐 ├── public/ │ ├── favicon.svg │ └── icons.svg ├── src/ │ ├── assets/ # hero.png / svelte.svg / vite.svg │ ├── lib/ │ │ └── Counter.svelte # 演示 $state 的计数组件 │ ├── App.svelte │ ├── app.css │ └── main.ts # Svelte 5 应用入口 ├── index.html ├── package.json ├── svelte.config.js ├── tsconfig.json # project references 根配置 ├── tsconfig.app.json # 应用代码src ├── tsconfig.node.json # Node 侧vite.config.ts ├── vite.config.ts └── _gitignore # 脚手架生成时重命名为 .gitignore使用方式是在目标目录执行模板的 README 即面向该使用场景编写npm create vitelatest my-app -- --template svelte-ts cd my-app npm install npm run dev推荐 IDE 配置VS Code Svelte 扩展模板 README 给出的推荐 IDE 组合是VS Code Svelte 官方 VS Code 扩展扩展 ID 为svelte.svelte-vscode。更值得注意的机制是README 提到其他模板往往只在 README 里间接推荐扩展而本模板额外提供了.vscode/extensions.json文件。从 _gitignore 可以看到.vscode/*目录默认被忽略、仅保留extensions.json进入版本控制# Editor directories and files .vscode/* !.vscode/extensions.json而该文件的内容只有一条推荐{ recommendations: [svelte.svelte-vscode] }其作用是用户用 VS Code 打开由模板生成的项目时VS Code 会主动弹出提示建议安装 Svelte 扩展从而保证.svelte文件的语法高亮、补全等 IntelliSense 能力开箱即用。技术选型为什么用这个模板而不是 SvelteKit模板 README 的 Technical considerations 一节直接回答了两个高频问题以下完整继承其结论并结合仓库现状说明。为什么用这个模板而不是 SvelteKitSvelteKit 自带一套路由方案这对部分用户而言并非首选SvelteKit 本质是一个恰好底层使用 Vite 的框架而不是一个纯粹的 Vite 应用。本模板的设计目标是包含尽可能少的内容让人能以最简形态启动 Vite TypeScript Svelte 项目同时在开发体验上兼顾 HMR 与 IntelliSense。它的功能定位与create-vite的其他模板对齐适合初学者入门 Vite Svelte 项目。README 同时指出该模板的结构刻意与 SvelteKit 保持相似以便日后需要 SvelteKit 的扩展能力与可扩展性时能够平滑迁移。TypeScript 配置体系project references 与 types模板的 TypeScript 采用project references拆分为应用侧与 Node 侧两个子项目。根 tsconfig.json 只负责引用不直接编译任何文件{ files: [], references: [ { path: ./tsconfig.app.json }, { path: ./tsconfig.node.json } ] }应用侧tsconfig.app.jsontsconfig.app.json 继承tsconfig/svelte的官方共享配置并在此基础上针对 Svelte Vite 场景做了关键定制{ extends: tsconfig/svelte/tsconfig.json, compilerOptions: { tsBuildInfoFile: ./node_modules/.tmp/tsconfig.app.tsbuildinfo, target: es2023, module: esnext, types: [svelte, vite/client], allowArbitraryExtensions: true, noEmit: true, allowJs: true, checkJs: true, moduleDetection: force }, include: [src/**/*.ts, src/**/*.js, src/**/*.svelte] }逐项解读types: [svelte, vite/client]显式引入svelteSvelte 编译相关类型与vite/clientimport.meta.env、?.svg/?.png等资源导入声明两类全局类型使import logo from ./assets/svelte.svg这类资源导入在类型检查下合法。这与 App.svelte 中直接import svelteLogo from ./assets/svelte.svg的写法相配套。target: es2023/module: esnext/noEmit: true产物交给 Vite/Rolldown 处理TypeScript 只负责类型检查noEmitesnext模块形态匹配 ESM 打包器。allowArbitraryExtensions允许导入带任意扩展名的模块配合 Svelte 文件的模块解析需要。include覆盖src下的.ts、.js与.svelte文件——svelte-check会基于这份配置对.svelte文件做完整类型检查见后文check脚本。注释中特别提示allowJs设为false并不能阻止在.svelte文件里写 JavaScript这直接引出了下一节的设计取舍。关于 global.d.ts 与compilerOptions.types的取舍README 专门回答了为什么用global.d.ts而不是jsconfig.json/tsconfig.json里的compilerOptions.types设置compilerOptions.types会屏蔽掉所有未显式列出的类型声明包而使用三斜杠引用/// reference types... /的global.d.ts方式既能保留 TypeScript接受整个工作区类型信息的默认行为又能叠加svelte与vite/client的类型。需要说明的是从当前仓库的模板实现看tsconfig.app.json 已经改为通过types: [svelte, vite/client]显式声明这两类类型同时include限定了src范围README 中的讨论可视为对这一设计问题的原始论证。两种方案的核心权衡一致types白名单更严格、可预测三斜杠引用则保留工作区默认类型发现。Node 侧tsconfig.node.jsontsconfig.node.json 单独覆盖 vite.config.ts采用 Bundler mode 的一整套现代 lint 型编译选项{ compilerOptions: { target: es2023, lib: [ES2023], types: [node], module: nodenext, allowImportingTsExtensions: true, verbatimModuleSyntax: true, moduleDetection: force, noEmit: true, noUnusedLocals: true, noUnusedParameters: true, erasableSyntaxOnly: true, noFallthroughCasesInSwitch: true }, include: [vite.config.ts] }要点types: [node]让配置文件内可以使用 Node 全局module: nodenextverbatimModuleSyntax保证import语法与 Node 模块解析语义一致erasableSyntaxOnly要求只使用可被纯文本擦除的 TS 语法不允许需要编译期转换的 enum 等这也是 Svelte/Vite 生态对轻量 TS 的常见约束。为什么在 TS 模板中启用allowJs这是 README 里论证最充分的一个决策其结论值得原样继承allowJs: false确实能阻止项目中出现.js文件但无法阻止在.svelte文件内部使用 JavaScript 语法——所以对.svelte单文件组件来说禁用 JS 文件并不彻底更糟的是allowJs: false会连带强制checkJs: false落入两全不得的局面既不能保证整个代码库都是 TypeScript又让现存 JavaScript 丧失了更好的类型检查此外混合代码库本身存在合理的使用场景例如渐进式迁移中的项目。当前模板的落地方式是在 tsconfig.app.json 中同时打开allowJs: true与checkJs: true并附注释说明默认对.svelte与.js文件中的 JS 做类型检查若希望 JS 使用动态类型可关闭checkJs。即允许 JS 存在但对它保持严格检查。构建链路vite.config.ts 与 package.json 脚本Vite 配置只有三行核心内容——注册 Svelte 官方 Vite 插件// vite.config.ts import { svelte } from sveltejs/vite-plugin-svelte import { defineConfig } from vite // https://vite.dev/config/ export default defineConfig({ plugins: [svelte()], })配套的 svelte.config.js 同样是空配置占位仅标注了sveltejs/vite-plugin-svelte的SvelteConfig类型留待用户按需扩展预处理器、编译选项等。package.json 定义了四个脚本与完整依赖清单版本以当前仓库为准{ name: vite-svelte-ts-starter, private: true, type: module, scripts: { dev: vite, build: vite build, preview: vite preview, check: svelte-check --tsconfig ./tsconfig.app.json tsc -p tsconfig.node.json }, devDependencies: { sveltejs/vite-plugin-svelte: ^7.3.0, tsconfig/svelte: ^5.0.8, types/node: ^24.13.3, svelte: ^5.57.0, svelte-check: ^4.7.6, typescript: ~6.0.2, vite: ^8.2.2 } }各脚本职责脚本命令作用devvite启动开发服务器含.svelte文件 HMRbuildvite build产物构建ESM 打包 资源处理previewvite preview本地预览build产物checksvelte-check --tsconfig ./tsconfig.app.json tsc -p tsconfig.node.json双阶段类型检查先由svelte-check按应用侧配置检查src含.svelte再由tsc检查 Node 侧配置注意check脚本显式传入了--tsconfig ./tsconfig.app.json这正是 project references 拆分的直接收益svelte-check只看应用侧语义tsc只看 Node 侧互不干扰。应用代码Svelte 5 的 mount 入口与 $state入口 src/main.ts 使用 Svelte 5 的mountAPI替代旧版new App({ target })import { mount } from svelte import ./app.css import App from ./App.svelte const app mount(App, { target: document.getElementById(app)!, }) export default appCounter.svelte 则演示了 Svelte 5 的响应式 runescript langts let count: number $state(0) const increment () { count 1 } /script button typebutton classcounter onclick{increment} Count is {count} /buttonindex.html 中以div idapp/div作为挂载点并用script typemodule src/src/main.ts引入入口App.svelte 组合了Counter组件、logo 资源导入与静态部署图标use href/icons.svg#...并提示编辑src/App.svelte保存以测试 HMR。HMR 为什么不保留组件局部状态README 的最后一个 FAQ 涉及一个高频困惑HMR 更新后为什么组件里的局部状态如Counter的count被重置结论是HMR 的状态保持存在一系列坑。由于其行为经常出人意料svelte-hmr与sveltejs/vite-plugin-svelte都默认禁用了状态保持。README 给出的工程化对策是把需要跨 HMR 更新存活的状态提升到外部 store——外部 store 模块不会被组件自身的 HMR 替换掉因此状态得以保留。README 给出的最小示例// store.ts // 一个极简的外部 store import { writable } from svelte/store export default writable(0)需要指出该示例沿用了svelte/store的writable经典写法在 Svelte 5 中同样可以直接用模块级$state模块只会被 HMR 失效一次组件内局部状态则会被重置达到类似目的但 README 给出的writable外部 store 方案在 4/5 版本下都通用是文档钦定的稳妥路径。总结svelte-ts模板展示了 Vite 生态最小可用脚手架的完整设计思路结构最小仅入口、根组件、演示组件与全局样式无路由、无状态库工程严格project references 拆分应用/Node 两侧 TS 配置svelte-checktsc双检查脚本allowJs/checkJs兼顾混合代码库DX 保障.vscode/extensions.json自动推荐 Svelte 扩展vite/client类型让资源导入合法化迁移友好目录结构刻意对齐 SvelteKit为日后升级预留通道。结合 README 与上述源码文件tsconfig.app.json、package.json、src/main.ts即可完整复现该模板从脚手架生成、本地开发到类型检查、构建预览的全流程。【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考