后端微服务【免费下载链接】loopback-nextLoopBack makes it easy to build modern API applications that require complex integrations.项目地址https://gitcode.com/gh_mirrors/lo/loopback-next点击查看免费下载LoopBack 4 官方 CLIlb4在生成每个新项目时都会在项目根目录自动放入一份DEVELOPING.md开发指南指导开发者如何用 Visual Studio Code 或任意编辑器完成持续编译 测试 代码规范检查的日常开发循环。本文以该模板文档为核心结合仓库中的生成器源码与loopback/build工具链实现完整讲解这套开箱即用的开发工作流读完后你将能在自己生成的项目中熟练配置 VSCode、理解build:watch/test:dev等命令的真实行为并学会排查编译错误、测试失败与 lint 报错。这份 DEVELOPING.md 从哪里来项目生成器的模板复制机制DEVELOPING.md并不是某篇孤立的随笔而是 LoopBack 4 CLI 项目生成器的公共模板文件之一位于 packages/cli/generators/project/templates/DEVELOPING.md。同目录下还放着package.json.ejs、package.plain.json.ejs、tsconfig.json.ejs和_.gitignore等模板它们共同定义了每个新生成项目的基础骨架。生成器在执行scaffold()时会先通过copyTemplatedFiles把../../project/templates/**/*下所有公共文件复制到目标项目根目录见 packages/cli/lib/project-generator.js#L260-L274// First copy common files from ../../project/templates this.copyTemplatedFiles( this.templatePath(../../project/templates/**/*), this.destinationPath(), { project: this.projectInfo, packageManager: this.config.get(packageManager), author: this.user.git.email() ? {name: this.user.git.name(), email: this.user.git.email()} : null, }, );因此任何通过lb4 app或lb4 extension生成的项目都会自带一份同样的DEVELOPING.md文件名中的点号被保留.前缀文件如.gitignore才需要特殊改名处理。也就是说这份文档描述的工作流适用于所有新生成的 LoopBack 4 应用与扩展项目而非仅针对 LoopBack 官方仓库本身。如果你想看更全面的仓库级贡献与开发规范可以参考 docs/DEVELOPING.md。第一步VSCode 环境准备两个必备扩展模板文档开门见山LoopBack 团队使用 Visual Studio Code 进行开发并推荐用户同样使用 VSCode。在开始日常开发前需要安装以下两个扩展ESLint 扩展提供实时的代码规范检查把 lint 错误直接显示在 VSCode 的 PROBLEMS 面板中支持保存时自动修复。Prettier 扩展提供代码格式化能力配合模板项目中的prettier脚本保持代码风格统一避免格式化类 diff。这两个扩展与项目package.json中配置的eslint/prettier:check脚本见下文命令与底层工具链一节一一对应。安装后无需额外配置.vscode/settings.json因为模板项目的 lint 与格式化均通过 npm scripts 驱动VSCode 的任务机制tasks会直接调用这些脚本。VSCode 开发工作流一个快捷键闭环模板文档给出了两条 VSCode 专属的操作路径分别对应编译与测试检查两个环节。启动构建任务CmdShiftB按下CmdShiftBWindows/Linux 为CtrlShiftB启动构建任务其效果是在后台运行 TypeScript 编译器并进入 watch 模式——你每次保存文件编译器都会自动重新编译改动即时生效。编译错误的呈现方式也做了明确分工编译错误会显示在 VSCode 的PROBLEMS窗口不会弹出打断输入的终端或对话框避免干扰编码节奏。这条快捷键对应的实际命令是npm run build:watch在模板 package.json.ejs 中定义为build: lb-tsc, build:watch: lb-tsc --watchlb-tsc是loopback/build提供的 TypeScript 编译封装见下文工具链解析--watch直接透传给 TypeScript 编译器的tsc --watch实现增量监听编译。值得一提的是模板 tsconfig.json.ejs 中开启了incremental: true非loopback/build场景下配合 watch 模式可以显著减少重复编译的开销。运行测试与 lint 任务CmdShiftP → Run Rest Task从命令面板CmdShiftP执行Run Rest Task会重新运行测试套件并对代码同时做编程错误与风格错误检查。错误呈现方式lint 错误显示在 VSCode 的 PROBLEMS 窗口测试失败只打印到终端输出不会出现在 PROBLEMS 面板中。这条任务实际执行的是npm run test:dev脚本在模板 package.json 中生成test: lb-mocha --allow-console-logs \dist/__tests__\, posttest: npm run lint, test:dev: lb-mocha --allow-console-logs dist/__tests__/**/*.js npm run posttest,即先用lb-mocha跑一遍编译产物dist/__tests__下的全部测试测试通过后再追加执行linteslintprettier:check。注意test:dev使用的是已编译的dist目录下的 JS 文件因此要求先运行build:watch或build完成编译——这正是文档要求先启动构建任务、再运行测试任务的原因。其他编辑器 / IDE两条终端命令的工作流不使用 VSCode 的开发者同样有标准流程模板文档将其拆成两个终端窗口/标签页职责完全分离窗口一持续构建npm run build:watch打开一个终端窗口/标签页运行npm run build:watchTypeScript 编译器进入 watch 模式随文件变化持续重编译。与 VSCode 场景不同这里的编译错误会直接打印到终端你需要根据输出定位问题。窗口二测试与检查npm run test:dev在主终端窗口/标签页运行npm run test:dev该命令会重新运行测试套件并执行 lint 检查每当你有一批新改动需要验证时就手动运行一次。测试失败与 lint 错误都会打印到终端。这种一个窗口持续编译、一个窗口按需测试的模式本质上与 VSCode 的CmdShiftB Run Rest Task 是同一套工作流build:watch↔ 构建任务test:dev↔ 测试任务只是呈现方式从图形面板换成了终端输出。模板文档同时给出两套说明正是为了兼顾不同编辑器的开发者。命令与底层工具链解析lb-tsc / lb-mocha / lb-eslint / lb-prettier模板项目脚本中大量出现的lb-*前缀命令全部来自loopback/build包。该包的 package.json 中注册了如下二进制命令bin: { lb-tsc: ./bin/compile-package.js, lb-ttsc: ./bin/compile-package.js, lb-eslint: ./bin/run-eslint.js, lb-prettier: ./bin/run-prettier.js, lb-mocha: ./bin/run-mocha.js, lb-nyc: ./bin/run-nyc.js, lb-clean: ./bin/run-clean.js }各命令的职责见 packages/build/README.md命令底层工具职责lb-tscTypeScripttsc编译 TypeScript并把非.ts资源文件复制到输出目录lb-eslintESLint运行代码规范检查支持--report-unused-disable-directiveslb-prettierPrettier代码格式化-l只检查、--write直接改写lb-mochaMocha执行测试用例lb-cleanrimraf 等清理dist、*.tsbuildinfo、.eslintcache等构建产物这些脚本有一个共同特性优先从目标项目自身依赖中寻找对应 CLI找不到再回退到loopback/build内置的版本因此升级工具链时无需改动项目脚本。为什么test脚本里要带--allow-console-logs模板中测试脚本统一写作lb-mocha --allow-console-logs dist/__tests__。查看 packages/build/bin/run-mocha.js 的实现可以知道默认情况下lb-mocha会注入fail-on-console-logs机制配合--no-warnings任何在测试中向控制台打印输出的代码都会导致测试失败以强制开发者通过断言而非日志来验证行为if (allowConsoleLogsIx -1) { // Fail any tests that are printing to console. mochaOpts.unshift( --no-warnings, // Disable node.js warnings --require, require.resolve(../src/fail-on-console-logs), ); }传入--allow-console-logs后该拦截会被移除允许测试打印日志——这是模板项目为日常开发调试特意保留的开关与 CI 场景下更严格的默认行为形成了对比。相关实现位于 packages/build/src/fail-on-console-logs.js。lb-eslint的配置自动发现模板项目的 lint 脚本为lb-eslint --report-unused-disable-directives .。在 packages/build/bin/run-eslint.js 中可以看到lb-eslint会自动探测项目根目录的.eslintrc.js/.eslintrc.json与.eslintignore并作为-c与--ignore-path传入无需在命令行里手动指定配置文件const eslintConfigFile isConfigSet ? null : utils.getConfigFile(.eslintrc.js, .eslintrc.json); const eslintIgnoreFile utils.getConfigFile(.eslintignore);这也是为什么Run Rest Task跑完测试后紧接着的 lint 检查能立刻反映代码风格问题。编译配置的两种形态模板 tsconfig.json.ejs 会根据生成选项生成两种配置使用loopback/build时extends官方公共配置 packages/build/config/tsconfig.common.json仅覆盖outDirdist与rootDirsrc不使用loopback/build纯 TypeScript 项目时内联完整配置包括experimentalDecorators、emitDecoratorMetadata、strictNullChecks、incremental、target: es2017、module: commonjs等并排除node_modules、dist与*.d.ts。无论哪种形态编译输出都统一落在dist/与test:dev扫描dist/__tests__/**/*.js的约定保持一致。实战要点小结把模板文档的两套工作流合并成一张对照表便于任何编辑器的开发者快速上手环节VSCode 操作命令行操作实际执行的脚本持续编译CmdShiftB构建任务npm run build:watchlb-tsc --watch测试 lintCmdShiftP→ Run Rest Tasknpm run test:devlb-mocha ... npm run lint编译错误位置PROBLEMS 面板终端输出—lint 错误位置PROBLEMS 面板终端输出lb-eslint自动发现配置测试失败位置终端输出终端输出lb-mocha默认拦截 console 日志日常开发的标准节奏是先保证build:watch在运行编译零错误再按需触发测试任务——因为测试执行的是dist下已编译的代码只有先编译、再测试改动才能被正确验证。若出现编译错误优先看 VSCode PROBLEMS 面板或build:watch终端输出定位到具体文件若测试失败则到运行test:dev的终端查看 Mocha 的失败详情。这套工作流的设计初衷是让编辑 → 编译 → 测试 → 检查形成一个无摩擦的循环编译与检查结果即时可见测试结果清晰可控。由于DEVELOPING.md会随lb4生成器自动复制到每个新项目你完全可以把它当作项目自带的开发手册随时回看这几条命令与它们的快捷键映射。赞分享后端微服务【免费下载链接】loopback-nextLoopBack makes it easy to build modern API applications that require complex integrations.项目地址https://gitcode.com/gh_mirrors/lo/loopback-next点击查看免费下载相关推荐LoopBack 4 的 lb4 update 命令详解如何与 CLI 模板联动升级 loopback/* 依赖LoopBack 4 的 lb4 update 命令详解如何与 CLI 模板联动升级 loopback/ 依赖 lb4 update 是 LoopBack后端微服务Cellpose 4 安装与实战指南从 Cellpose-SAM 模型到 GUI 与命令行的完整工作流Cellpose 4 安装与实战指南从 Cellpose SAM 模型到 GUI 与命令行的完整工作流 本文以仓库 README.md https://lin人工智能深度学习计算机视觉图像处理科研生物信息学gmaps终极指南如何在Jupyter Notebook中创建交互式Google地图gmaps终极指南如何在Jupyter Notebook中创建交互式Google地图 gmaps是一款专为数据科学家设计的强大Python库让你能在Jupy数据分析上一篇深入 Warp 的 CLI Agent 尾部空白行裁剪机制从 len_displayed() 到 content_len() 的实现剖析下一篇Smartstore模块本地化完整指南翻译资源与多语言管理最佳实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考