分类： Lighthouse v5
-
在 Laravel 6 和 Lighthouse 5 环境下，使用 @rules 指令应用 exists 验证规则时，自定义属性名无法按语言区域正确翻译，导致返回的验证消息中包含原始字段名而非本地化名称。经过排查，排除了 nwidart/laravel-modules 版本及语言文件位置的影响，确认原因在于 Lighthouse 5 对验证属性的支持不够彻底。目前决定暂不编写自定义验证器类，暂时接受在非英语环境下属性名未被完全翻译的现状。
-
针对在 Laravel 6、LightHouse 5 和 PHPUnit 环境中编写 Mutation 测试时需要删除缓存数据的需求，文章参考了 REST API 测试中先操作数据库再请求删除的思路。通过调整测试策略，先直接操作缓存生成明确的缓存标识，随后执行 HTTP API 请求进行删除操作。实际运行结果显示，该方案成功通过测试，实现了对删除缓存标识 Mutation 的有效验证。
-
本文介绍了在 Laravel 6 结合 Lighthouse 5 及模块化架构下，为 GraphQL API 创建自定义验证规则的过程。通过在模块中生成规则类，编写逻辑判断缓存标识是否存在，并在 Schema 文件中使用 @rules 指令引用该规则，实现了验证逻辑的复用。文章还详细说明了如何配置模块内的多语言文件以返回本地化错误消息，最终完成了包含中英文错误提示的接口功能测试。
-
在 Laravel 6.20.43 与 Lighthouse 5.45.0 环境下遇到类 ClearsSchemaCache 已弃用的问题，该类原用于在测试前清除模式缓存。查阅文档后，决定将其替换为 RefreshesSchemaCache 类。编辑指定模块的测试文件并完成代码替换后，重新运行测试并通过验证。
-
本文介绍了在 Laravel 6 结合 Module 与 Lighthouse 框架中实现安全验证的具体流程。通过使用 @rules 指令应用 Exists 规则，针对请求参数 themeId 进行是否存在的数据表校验。经过测试验证规则有效，并利用 Laravel Telescope 查看 SQL 语句。同时验证了该规则会自动读取表前缀，当前缀变更时验证依然生效，无需额外调整。
-
文章记录了在 Lighthouse 5 中基于 PHPUnit 编写 Mutation 测试的过程。通过编辑 GraphQL 测试文件解决了输入类型报错问题，并针对因请求参数重复导致验证失败的断言错误，将变量 key 的值改为基于时间戳生成。该方法在配置单独测试数据库的基础上，有效避免了多次运行测试时的参数冲突，确保了测试结果的稳定性。
-
在 Laravel 6 项目中遇到 Target [Interface] is not instantiable 报错，经排查发现 ThemeStoreServiceProvider.php 文件中 use 路径引用错误，删除多余的 Theme\ 路径后解决类未定义问题。随后执行 php artisan list 再次报错，提示目标类 SyncCommand 不存在，检查确认该类路径下无文件后，删除了 ServiceProvider 中相关的调用代码，最终命令执行成功。
-
本文介绍了在 Laravel 6 结合 Lighthouse 和 Module 框架下实现请求参数安全验证的流程。针对包含多条复杂规则的变更操作，通过创建专门的验证器类来处理诸如数据库记录存在性、路径格式、后缀名限制及数据唯一性等校验需求，并将其从应用目录迁移至 Module 模块中。最终在 GraphQL 文件中使用 @validator 指令指定该类，经测试确认验证规则有效且 SQL 语句执行正常。
-
文章以在 Shopify 创建资源为例，记录了从 REST 迁移到 GraphQL 的实践过程。由于 GraphQL 未提供创建模板文件的 API，作者参考 productCreate 接口进行了尝试。通过在后台手动添加产品并复制网络请求参数，解决了因 GraphQL 版本不一致导致字段不匹配的问题。经过多次修正查询与变量结构，最终成功创建了产品，并总结了请求与响应的最终结构及报错处理方式。
-
在编写 Lighthouse 5 的自动化测试用例时，PhpStorm 无法自动完成且无法找到 assertJson 方法的声明。经排查，这是因为 nuwave/lighthouse v5.36.0 与 Laravel Framework 6.20.44 版本不匹配，导致对象路径异常。通过 Composer 将 nuwave/lighthouse 回退至 ~4.10.1 版本后，PhpStorm 恢复了代码自动完成功能，问题得到解决。