Sails 项目 assets/dependencies 目录：客户端依赖的正确存放位置与加载顺序机制
Sails 项目 assets/dependencies 目录客户端依赖的正确存放位置与加载顺序机制【免费下载链接】sailsRealtime MVC Framework for Node.js项目地址: https://gitcode.com/gh_mirrors/sa/sails导读本文聚焦 Sails 应用解剖结构中的assets/dependencies/目录说明它的准确定位存放 Vue.js、Bootstrap、jQuery 等第三方客户端依赖而非团队自研代码、先于其他资源加载的约定行为以及这一行为背后的资产管道编排机制——tasks/pipeline.js与sails-linkerGrunt 任务的完整配合流程。读完本文你将掌握在 Sails 项目中正确组织前端第三方依赖、控制其注入顺序、并在开发与生产环境下分别处理这些资源的具体方法。一、assets/dependencies/是什么在 Sails 新生成应用的默认结构中assets/目录承载了应用需要静态托管的所有文件应用启动后assets/newFolder/data.txt这样的文件可通过http://localhost:1337/newFolder/data.txt直接访问见 assets 目录说明。而其中的assets/dependencies/子目录有一条非常明确的规则只要是你或你的团队编写的代码就不属于这个文件夹。assets/dependencies/是专门用来存放客户端第三方依赖的地方例如 Vue.js、Bootstrap 或 jQuery。这个文件夹里可以包含客户端 JavaScript 文件、样式表甚至图片Web App 模板中即有示例见 dependencies 目录说明。这一约定把两类性质完全不同的前端资源区分开来目录存放内容示例assets/dependencies/第三方、来自外部的客户端依赖Vue.js、Bootstrap、jQuery、Socket.IO 客户端assets/js/、assets/styles/应用自身的客户端代码自研模块、业务逻辑、自定义样式从源码结构看这种分离是 Sails 约定优于配置 哲学的体现框架通过目录位置即可推断资源的性质而不需要额外的声明文件。二、核心约定依赖先于其他资源加载assets/dependencies/中最关键的行为约定是assets/dependencies/文件夹中的 JavaScript 文件和样式表会最先被加载排在你的其他资源之前。这一约定行为由 tasks/pipeline.js 编排。如果你需要调整行为例如让某些客户端依赖必须比其他依赖更早加载就应该去修改该文件。这条约定背后是一个简单而重要的现实需求第三方依赖如 jQuery通常是应用自身脚本的前置条件——自研代码在运行时引用了 jQuery 等全局对象因此必须保证依赖先于应用脚本注入页面。三、底层机制pipeline.js 与 sails-linker 的配合3.1 资产管道Asset PipelineSails 的资产管道是组织将要被注入到视图中的资产的地方位于tasks/pipeline.js文件见 Task automation 文档。配置该文件使用 Grunt 的任务文件配置语法与通配符/glob/splat 匹配模式内容分为三个部分要注入的 CSS 文件CSS Files to Inject将作为link标签注入 HTML插入位置是视图中出现的!--STYLES--!--STYLES END--注释之间要注入的 JavaScript 文件JavaScript Files to Inject将作为script标签注入 HTML插入位置是!--SCRIPTS--!--SCRIPTS END--注释之间。文件按数组中的顺序注入因此依赖文件的路径必须放在依赖它们的文件之前——这正是dependencies/目录约定与 pipeline 数组顺序两个机制相互呼应的关键点要注入的模板文件Template Files to Inject会被编译为 JST 函数并放入jst.js文件该文件再以script标签注入到!--TEMPLATES--!--TEMPLATES END--注释之间。pipeline.js 还支持 Grunt 风格的通配符表达式来匹配多个文件并用表达式前的!来排除文件见 pipeline.js 文档。3.2 sails-linker自动注入脚本与样式标签负责真正执行注入动作的是名为sails-linker的 Grunt 任务其配置位于 tasks/config/sails-linker.js。它的功能是自动向指定的 HTML 和/或 EJS 文件注入script标签和link标签通过配置中的startTag和endTag分隔符确定插入点。如果某个脚本或样式表的注入是仅在包含!--SCRIPTS--!--SCRIPTS END--和/或!--STYLES--!--STYLES END--标签的文件中进行的见 Default tasks 文档。这些标签包含在新 Sails 项目默认的views/layouts/layout.ejs文件中。如果不希望项目使用 linker直接移除这些标签即可。linkAssets任务列表本身不直接被使用它是default任务列表和watch任务的支撑模块仅在grunt-sails-linker包启用时生效见 linkAssets.js 文档。四、开发与生产环境的差异处理sails-linker在两种环境下行为不同见 sails-linker.js 文档4.1 开发模式默认默认情况下会为以下内容注入标签应用的客户端 JavaScript 文件CSS 样式表templates/目录下预编译的客户端 HTML 模板详见jst任务。此外如果assets/styles/importer.less存在它会先被编译为 CSS然后注入对应的link标签如果assets/js/中存在 CoffeeScript 文件它们同样会被编译为 JavaScript 后注入。4.2 生产模式NODE_ENVproduction所有样式表包括全部.css文件和assets/styles/importer.less被压缩合并为单个.css文件由tasks/config/cssmin.js任务处理所有客户端脚本包括.js和.coffee文件被压缩合并为单个.js文件由tasks/config/uglify.js任务处理预编译的客户端 HTML 模板JST也可以在sails-linker:prodJs运行时与其他脚本一并压缩但由于这可能改变前端代码的行为默认不包含。如果使用 JST 模板并希望它们进入压缩包从tasks/register/prod.js的 tasklist 数组中移除clientSideTemplates然后修改tasks/config/uglify.js把编译产物.tmp/public/jst.js加入其src数组。这种差异保证了开发环境的热更新与可读性同时让生产环境获得更小的体积与更少的请求数。五、触发机制何时执行这些任务Sails 会在特定命令下自动运行tasks/register/中的任务见 tasks 目录文档 与 Task automation 文档命令执行的任务说明sails liftdefaulttasks/register/default.js编译 LESS、CoffeeScript、客户端 JST 模板并从动态视图和静态 HTML 页面自动链接它们sails lift --prodprodtasks/register/prod.js与default职责相同另加脚本与样式表的压缩sails wwwbuildtasks/register/build.js将资产编译到www子目录而非.tmp/public便于用 Apache 或 Nginx 托管sails www --prodbuildProdtasks/register/buildProd.js同build并额外做资源优化在开发模式下watch任务会监听assets/文件夹的文件变更并重新运行相应任务如 LESS 编译让你无需重启 Sails 服务器即可看到资产变化见 Default tasks 文档。六、实战向 assets/dependencies 添加第三方依赖以在页面中使用 jQuery 为例遵循 Sails 的约定流程将 jQuery 文件放入assets/dependencies/例如assets/dependencies/jquery.min.js在tasks/pipeline.js的jsFilesToInject数组中将其路径放在应用自身脚本之前确保注入顺序正确确保布局文件views/layouts/layout.ejs中包含!--SCRIPTS--!--SCRIPTS END--注释标记sails-linker会在该位置注入script标签sails lift后依赖会在应用脚本之前被注入页面。如需调整默认顺序例如让某些依赖先于其他依赖加载直接修改tasks/pipeline.js中数组的排列顺序即可——这是官方文档明确指出的定制入口见 dependencies 目录说明。如果想在项目层面完全掌控依赖的引入也可以不使用自动注入手动在视图中书写script标签。此时应把对应文件从 pipeline 中排除避免重复加载。七、内置依赖示例sails.io.js在默认的 Sails 新应用中assets/dependencies/部分版本位于assets/js/dependencies/参见 socket client 文档会内置一个名为sails.io.js的文件。它是 Sails 提供 内建 WebSocket 功能的关键见 sails.io.js 目录说明它为 Socket.IO 添加若干自定义方法这些方法允许你在 Socket.IO 之上模拟 REST 客户端接口向 Sails 发送和接收 Socket.IO 消息其 API 模仿了你可能熟悉的 jQuery$.ajax模式。也就是说在浏览器中执行io.socket.post(/user)与向同一路由发起 HTTP POST 请求在 Sails 应用内的路由方式完全相同。底层原理是sails.io.js发出保留名称的 Socket.IO 消息Sails 解释后按应用的路由与蓝图配置路由到对应的 policies/controllers 等见 socket client FAQ。注意如果使用默认的 Grunt 资产管道自动注入脚本标签并且需要通过 HTML 属性或io.sails编程方式配置该客户端如设置autoConnect、environment、headers、url建议将sails.io.js从pipeline.js中排除改为显式script标签引入——这样你的配置代码会在 eager 自动连接 socket 开始连接之前执行详见 socket client 配置章节。八、常见问题与定制建议Q能否完全不用 Grunt可以。删除项目的 Gruntfile 或禁用 Grunt hook 即可见 tasks 目录文档也可以用sails new --withoutgrunt生成不含 Grunt 的应用或用sails new myCoolApi --no-frontend完全省略assets文件夹与前端导向的 Grunt 任务。Qpipeline.js 中能否使用通配符可以。Grunt 风格的通配符/glob/splat 表达式可用于匹配多个文件!前缀用于排除文件tasks/config/下的任务配置文件本身也使用同样的匹配模式见 pipeline.js 文档 与 Task automation 文档。Q不依赖自动链接时怎么办如果不想依赖自动资产链接automatic asset linking可以安全地忽略pipeline.js见 pipeline.js 文档改为在视图中手动书写资源标签。Q想替换默认的模板编译引擎以 Handlebars 替换默认的 underscore 模板为例需要四步安装grunt-contrib-handlebars、在tasks/config/handlebars.js中配置任务、修改tasks/pipeline.js中的模板 glob 模式、把tasks/register/compileAssets.js与tasks/register/syncAssets.js中的jst任务替换为handlebars任务最后卸载grunt-contrib-jst完整示例见 Task automation 文档。九、总结assets/dependencies/是 Sails 应用解剖结构中一个虽小但定位明确的目录它是第三方客户端依赖的专属家园通过tasks/pipeline.js中数组的有序排列与sails-linker的自动注入机制实现了依赖先于应用资源加载的约定行为。理解这一目录的边界不放团队自研代码与其背后的管道机制pipeline 顺序 → sails-linker 注入 → 开发/生产差异化处理是掌控 Sails 前端资产工作流的基础。相关文档可继续深入assets 目录总览、pipeline.js、sails-linker 配置、默认 Grunt 任务、任务自动化、socket 客户端参考。【免费下载链接】sailsRealtime MVC Framework for Node.js项目地址: https://gitcode.com/gh_mirrors/sa/sails创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考