标签： Lighthouse
-
本文探讨了在 Laravel 6 结合 Lighthouse 5 环境中，invoke 魔术方法的 $args 参数内部顺序与前端请求参数不一致的问题。经测试发现，直接转换 $args 或通过 Illuminate\Http\Request 获取请求参数，字段排序均会发生变化，而通过获取请求体的原始内容，则能确保与前端顺序完全一致，从而解决了字段顺序错位的问题。
-
程序在 Linux 环境下运行时报错 Failed to load type: OnlineStoreThemePreset，而本地 Windows 10 环境运行正常。排查后发现原因是 GraphQL Schema 缓存在 Redis 中未更新。通过执行 php artisan cache:clear 命令清除缓存后，接口请求恢复正常，问题得到解决。
-
本文针对 Lighthouse 中 resolver 对应的类方法 __invoke 未执行的问题进行排查。通过打印日志和调试调用栈确认构造函数正常执行但 __invoke 未被调用。对比其他正常执行的 resolver 类，发现调整 GraphQL 架构定义或解析类可恢复执行。最终定位问题根源在于该类方法内部使用了 yield 循环，删除后 __invoke 即可正常执行。
-
在使用 Lighthouse 过程中出现 Failed to load type: ThemeSettingRange 报错，经 GraphQL 客户端检查发现响应数据中 __typename 字段值为 ThemeSettingRange。通过调整实现方式，在该类型前添加 OnlineStore 前缀，成功解决了 Schema 定义中类型缺失的问题，使查询恢复正常。
-
在 Laravel 6 和 Lighthouse 5 环境下，使用 @rules 指令应用 exists 验证规则时，自定义属性名无法按语言区域正确翻译，导致返回的验证消息中包含原始字段名而非本地化名称。经过排查，排除了 nwidart/laravel-modules 版本及语言文件位置的影响，确认原因在于 Lighthouse 5 对验证属性的支持不够彻底。目前决定暂不编写自定义验证器类，暂时接受在非英语环境下属性名未被完全翻译的现状。
-
本文介绍了在 Laravel 6 结合 Module 与 Lighthouse 框架中实现安全验证的具体流程。通过使用 @rules 指令应用 Exists 规则，针对请求参数 themeId 进行是否存在的数据表校验。经过测试验证规则有效，并利用 Laravel Telescope 查看 SQL 语句。同时验证了该规则会自动读取表前缀，当前缀变更时验证依然生效，无需额外调整。
-
文章记录了在 Lighthouse 5 中基于 PHPUnit 编写 Mutation 测试的过程。通过编辑 GraphQL 测试文件解决了输入类型报错问题，并针对因请求参数重复导致验证失败的断言错误，将变量 key 的值改为基于时间戳生成。该方法在配置单独测试数据库的基础上，有效避免了多次运行测试时的参数冲突，确保了测试结果的稳定性。
-
本文介绍了在 Laravel 6 结合 Lighthouse 和 Module 框架下实现请求参数安全验证的流程。针对包含多条复杂规则的变更操作，通过创建专门的验证器类来处理诸如数据库记录存在性、路径格式、后缀名限制及数据唯一性等校验需求，并将其从应用目录迁移至 Module 模块中。最终在 GraphQL 文件中使用 @validator 指令指定该类，经测试确认验证规则有效且 SQL 语句执行正常。
-
在编写 Lighthouse 5 的自动化测试用例时，PhpStorm 无法自动完成且无法找到 assertJson 方法的声明。经排查，这是因为 nuwave/lighthouse v5.36.0 与 Laravel Framework 6.20.44 版本不匹配，导致对象路径异常。通过 Composer 将 nuwave/lighthouse 回退至 ~4.10.1 版本后，PhpStorm 恢复了代码自动完成功能，问题得到解决。