Skip to content

$rawfile和oh_modules支持原始文件资源的调用查找与定义跳转,单层架构、鸿蒙三层架构工程 - #152

Closed
frezs wants to merge 17 commits into
ohosvscode:nextfrom
guziapp:oh_modules-dev
Closed

$rawfile和oh_modules支持原始文件资源的调用查找与定义跳转,单层架构、鸿蒙三层架构工程#152
frezs wants to merge 17 commits into
ohosvscode:nextfrom
guziapp:oh_modules-dev

Conversation

@frezs

@frezs frezs commented Sep 21, 2025

Copy link
Copy Markdown

fix: lint

refactor(lsp): 重构项目检测与类型服务包装逻辑

  • 提取项目检测逻辑至独立的 ProjectDetectionService 服务
  • 加入 TypeScriptServiceWrapper,封装语言服务主机方法,增强JSON5文件访问防护
  • 将安全JSON5解析器 SafeJson5Parser 和全局错误处理 GlobalErrorHandler
    独立为工具类并在启动时初始化
  • 用 UriHelper 工具类安全解析URI并过滤依赖及配置文件
  • 优化文档打开事件的项目重新检测流程,避免无效检测和冗余代码
  • 改善全局错误捕获机制,使服务器异常时持续稳定运行
  • 删除冗余代码与注释,提升代码可维护性和清晰度

fix(lsp): 处理JSON5解析错误避免服务器崩溃

  • 实现安全的JSON5解析函数,拦截并处理非法内容解析异常
  • 包装TypeScript服务,添加错误处理保证服务稳定启动
  • 过滤有问题的JSON5配置文件,避免触发解析错误影响项目检测
  • 包装TypeScript语言服务Host相关方法,防止读取或判断有问题JSON5文件时报错
  • 添加未处理Promise拒绝时的堆栈错误日志输出,提升日志调试信息
  • 暂时注释ResourceWatcher导入调用,避免潜在问题
  • 新增安全JSON5解析工具,统一处理JSON5解析相关错误和日志记录

fix(lsp): 增强类型服务错误处理与URI解析安全

  • 添加全局未捕获异常和未处理Promise拒绝的日志处理,保证服务不中断
  • 实现安全的URI解析函数,处理特殊字符和潜在格式问题
  • 在文本文件打开时使用安全解析函数,过滤无效或依赖库路径
  • 捕获文本文件打开和项目检测中的异常,确保错误不会影响服务运行
  • 增强日志调试信息,提升异常和边界情况的可观察性

feat(project): 实现动态项目识别及根目录自动检测

  • 新增项目重新检测逻辑,根据打开文档动态判断是否需要重新识别项目类型
  • 实现从文档路径向上查找项目根目录的功能,支持识别oh-package.json5和package.json
  • 当文档不属于当前项目根目录或项目类型变化时,触发项目重新检测
  • 在文档打开事件监听中集成上述检测逻辑,实现自动切换项目根目录和类型
  • 初始化时设置当前项目根目录,保持状态同步
  • 添加详细日志输出,方便调试项目识别流程
  • 编写单元测试覆盖项目识别和重新检测的各种场景,保证功能正确性

feat(shared): 增强UnifiedProjectDetector项目检测能力

  • 实现多策略检测:当前目录、向上遍历、向下搜索
  • 引入检测策略和工作目录字段以支持更精细判断
  • 支持ArkTS子模块目录的识别与处理
  • 添加智能回退机制,提高未识别项目检测成功率
  • 优化缓存机制,避免频繁重复检测
  • 日志详细化,增强调试信息输出
  • 新增获取项目根目录及快速判断项目类型的静态方法

refactor(project): 重构并统一项目类型检测器逻辑

  • 将原LanguageServer内的ProjectDetector迁移至shared包,改名为UnifiedProjectDetector
  • 实现统一的项目类型检测工具,支持缓存并提供30秒TTL过期机制
  • 改进检测流程,优先判定oh-package.json5,兼顾build-profile.json5及oh_modules目录
  • 新增检测时间戳字段用于缓存管理,增加缓存清理接口
  • 替换LanguageServerConfigManager中项目检测调用,采用UnifiedProjectDetector静态方法
  • 更新测试用例,替换为统一的项目检测器调用
  • VSCode端SDK分析器使用统一项目检测逻辑,简化并统一包管理器类型识别流程
  • 删除冗余依赖与实例化,改用静态方法调用统一检测器
  • 增加日志输出,便于检测过程跟踪与调试

test: oh_modules模块解析功能单元测试

feat(oh_modules): 新增项目类型自动检测功能

新增 ProjectDetector 类用于自动识别项目类型(ArkTS 或 TypeScript),并根据项目特征自动配置包管理器类型(ohpm 或 npm)。在语言服务器初始化时自动调用项目检测逻辑,以优化对不同项目结构的支持。同时新增相关接口与枚举类型,完善项目检测能力。

feat(shared): 添加包管理器类型配置选项

在 client-options.ts 中新增 packageManagerType 字段,用于指定模块解析时使用的包管理器类型,
支持 'npm' 和 'ohpm' 两种选项,以增强对不同包管理器的支持和配置灵活性。

feat(vscode): 添加项目类型与包管理器自动检测功能

新增 detectPackageManagerType 方法,用于根据项目配置文件(如 oh-package.json5、build-profile.json5)
及目录结构自动识别项目类型,并判断应使用的包管理器(npm 或 ohpm)。该功能增强了 SDK 分析器的智能识别能力,
确保在不同项目环境下能正确加载相关依赖和工具链。

docs(readme): 更新资源引用导航和诊断功能说明

  • 新增对 $r() 资源引用的导航支持,代码中点击可直接跳转到对应资源文件或 JSON 配置
  • 新增对 $r() 资源引用的诊断支持,实时检测不存在的资源引用,并区分错误、警告或无提示诊断级别
  • 新增对 $rawfile() 资源引用的导航支持,代码中点击可直接跳转到对应的原始文件资源
  • 新增对 $rawfile() 资源引用的诊断支持,实时检测不存在的原始文件资源并支持多种诊断级别

feat(rawfile): 添加Rawfile文件路径智能补全功能

  • 新增Rawfile补全服务,支持对$rawfile()调用中路径的智能提示
  • 实现多种文件类型识别和优先级排序,提升补全准确度
  • 支持目录自动显示及插入尾部斜杠,优化用户体验
  • 采用模糊匹配算法和匹配度评分,实现智能模糊匹配
  • 增加补全项图标、详细说明及匹配度提示,提升界面信息丰富度
  • 集成资源解析器,确保补全项基于最新项目资源数据
  • 详细日志记录补全流程,便于调试与维护

feat(rawfile): 添加Rawfile资源诊断服务及相关配置支持

  • 新增RawfileDiagnosticService,用于检测$rawfile()调用中的资源引用问题
  • 在language-server入口集成Rawfile诊断服务,支持动态诊断级别配置
  • 扩展全局配置项,支持rawfileReferenceDiagnostic诊断级别设置
  • 增加VSCode扩展中Rawfile诊断配置监听并同步配置到语言服务器
  • 编写Rawfile诊断相关单元测试,覆盖错误、警告和无诊断等级行为
  • 编写Rawfile诊断功能综合测试,验证诊断生成及诊断消息源标识

update(res): 添加测试组件验证 rawfile 资源

feat(rawfile): 支持原始文件资源的调用查找与定义跳转

  • 在全局调用查找器中新增对 $rawfile() 函数调用的检测与解析功能
  • 扩展 BaseResourceService,提供查找所有及指定位置的 $rawfile() 调用方法
  • 新增 RawfileDefinitionService,实现对 $rawfile() 资源的定义跳转支持
  • 在语言服务器中集成 rawfile 资源定义服务
  • 资源解析器中增加 rawfile 资源索引和定位能力,支持文件与目录
  • 提供 parseRawfileReference 方法用于解析 rawfile 路径字符串
  • 新增单元测试覆盖 $rawfile() 的调用检测、定义跳转和资源解析功能
  • 升级 VSCode API 依赖版本以支持最新功能和兼容性维护

- 在全局调用查找器中新增对 $rawfile() 函数调用的检测与解析功能
- 扩展 BaseResourceService,提供查找所有及指定位置的 $rawfile() 调用方法
- 新增 RawfileDefinitionService,实现对 $rawfile() 资源的定义跳转支持
- 在语言服务器中集成 rawfile 资源定义服务
- 资源解析器中增加 rawfile 资源索引和定位能力,支持文件与目录
- 提供 parseRawfileReference 方法用于解析 rawfile 路径字符串
- 新增单元测试覆盖 $rawfile() 的调用检测、定义跳转和资源解析功能
- 升级 VSCode API 依赖版本以支持最新功能和兼容性维护
- 新增RawfileDiagnosticService,用于检测$rawfile()调用中的资源引用问题
- 在language-server入口集成Rawfile诊断服务,支持动态诊断级别配置
- 扩展全局配置项,支持rawfileReferenceDiagnostic诊断级别设置
- 增加VSCode扩展中Rawfile诊断配置监听并同步配置到语言服务器
- 编写Rawfile诊断相关单元测试,覆盖错误、警告和无诊断等级行为
- 编写Rawfile诊断功能综合测试,验证诊断生成及诊断消息源标识
- 新增Rawfile补全服务,支持对$rawfile()调用中路径的智能提示
- 实现多种文件类型识别和优先级排序,提升补全准确度
- 支持目录自动显示及插入尾部斜杠,优化用户体验
- 采用模糊匹配算法和匹配度评分,实现智能模糊匹配
- 增加补全项图标、详细说明及匹配度提示,提升界面信息丰富度
- 集成资源解析器,确保补全项基于最新项目资源数据
- 详细日志记录补全流程,便于调试与维护
- 新增对 $r() 资源引用的导航支持,代码中点击可直接跳转到对应资源文件或 JSON 配置
- 新增对 $r() 资源引用的诊断支持,实时检测不存在的资源引用,并区分错误、警告或无提示诊断级别
- 新增对 $rawfile() 资源引用的导航支持,代码中点击可直接跳转到对应的原始文件资源
- 新增对 $rawfile() 资源引用的诊断支持,实时检测不存在的原始文件资源并支持多种诊断级别
新增 `detectPackageManagerType` 方法,用于根据项目配置文件(如 oh-package.json5、build-profile.json5)
及目录结构自动识别项目类型,并判断应使用的包管理器(npm 或 ohpm)。该功能增强了 SDK 分析器的智能识别能力,
确保在不同项目环境下能正确加载相关依赖和工具链。
在 client-options.ts 中新增 packageManagerType 字段,用于指定模块解析时使用的包管理器类型,
支持 'npm' 和 'ohpm' 两种选项,以增强对不同包管理器的支持和配置灵活性。
新增 `ProjectDetector` 类用于自动识别项目类型(ArkTS 或 TypeScript),并根据项目特征自动配置包管理器类型(ohpm 或 npm)。在语言服务器初始化时自动调用项目检测逻辑,以优化对不同项目结构的支持。同时新增相关接口与枚举类型,完善项目检测能力。
- 将原LanguageServer内的ProjectDetector迁移至shared包,改名为UnifiedProjectDetector
- 实现统一的项目类型检测工具,支持缓存并提供30秒TTL过期机制
- 改进检测流程,优先判定oh-package.json5,兼顾build-profile.json5及oh_modules目录
- 新增检测时间戳字段用于缓存管理,增加缓存清理接口
- 替换LanguageServerConfigManager中项目检测调用,采用UnifiedProjectDetector静态方法
- 更新测试用例,替换为统一的项目检测器调用
- VSCode端SDK分析器使用统一项目检测逻辑,简化并统一包管理器类型识别流程
- 删除冗余依赖与实例化,改用静态方法调用统一检测器
- 增加日志输出,便于检测过程跟踪与调试
- 实现多策略检测:当前目录、向上遍历、向下搜索
- 引入检测策略和工作目录字段以支持更精细判断
- 支持ArkTS子模块目录的识别与处理
- 添加智能回退机制,提高未识别项目检测成功率
- 优化缓存机制,避免频繁重复检测
- 日志详细化,增强调试信息输出
- 新增获取项目根目录及快速判断项目类型的静态方法
- 新增项目重新检测逻辑,根据打开文档动态判断是否需要重新识别项目类型
- 实现从文档路径向上查找项目根目录的功能,支持识别oh-package.json5和package.json
- 当文档不属于当前项目根目录或项目类型变化时,触发项目重新检测
- 在文档打开事件监听中集成上述检测逻辑,实现自动切换项目根目录和类型
- 初始化时设置当前项目根目录,保持状态同步
- 添加详细日志输出,方便调试项目识别流程
- 编写单元测试覆盖项目识别和重新检测的各种场景,保证功能正确性
- 添加全局未捕获异常和未处理Promise拒绝的日志处理,保证服务不中断
- 实现安全的URI解析函数,处理特殊字符和潜在格式问题
- 在文本文件打开时使用安全解析函数,过滤无效或依赖库路径
- 捕获文本文件打开和项目检测中的异常,确保错误不会影响服务运行
- 增强日志调试信息,提升异常和边界情况的可观察性
- 提取项目检测逻辑至独立的 ProjectDetectionService 服务
- 加入 TypeScriptServiceWrapper,封装语言服务主机方法,增强JSON5文件访问防护
- 将安全JSON5解析器 SafeJson5Parser 和全局错误处理 GlobalErrorHandler
  独立为工具类并在启动时初始化
- 用 UriHelper 工具类安全解析URI并过滤依赖及配置文件
- 优化文档打开事件的项目重新检测流程,避免无效检测和冗余代码
- 改善全局错误捕获机制,使服务器异常时持续稳定运行
- 删除冗余代码与注释,提升代码可维护性和清晰度

fix(lsp): 处理JSON5解析错误避免服务器崩溃

- 实现安全的JSON5解析函数,拦截并处理非法内容解析异常
- 包装TypeScript服务,添加错误处理保证服务稳定启动
- 过滤有问题的JSON5配置文件,避免触发解析错误影响项目检测
- 包装TypeScript语言服务Host相关方法,防止读取或判断有问题JSON5文件时报错
- 添加未处理Promise拒绝时的堆栈错误日志输出,提升日志调试信息
- 暂时注释ResourceWatcher导入调用,避免潜在问题
- 新增安全JSON5解析工具,统一处理JSON5解析相关错误和日志记录
@changeset-bot

changeset-bot Bot commented Sep 21, 2025

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 4ef4c53

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

- 新增 CodeLinterConfigManager 类,负责加载和管理项目中的代码linter配置
- 支持从 code-linter.json5、.eslintrc.json5、.eslintrc.json 等文件读取配置
- 实现格式化配置提取,映射 ESLint/TypeScript-ESLint 规则到格式化参数
- 修改诊断服务,接入代码linter配置,支持规则开关及诊断级别自定义
- 修改格式化服务,支持基于代码linter配置的格式化参数动态调整
- 在语言服务器初始化时创建并加载代码linter配置管理器实例
- 监听配置文件变更,自动重新加载代码linter配置
- 增加文件匹配逻辑,诊断服务仅对匹配文件执行规则检查
- 提高日志记录,输出配置加载与提取详情,便于调试维护
- 实现了对以 **/dirname/** 开头和结尾的路径匹配的特殊处理
- 修正通配符转换逻辑,更精确匹配多层目录和单层目录字符
- 添加了基于真实文件系统环境的单元测试覆盖配置加载、格式化提取及规则访问
- 测试支持配置文件热更新和备用配置文件查找
- 验证文件匹配和忽略规则的正确性,确保模式匹配准确无误
@Groupguanfang

Copy link
Copy Markdown
Collaborator

目前采用 @arkts/project-detector 完整实现了项目功能资源解析,故此PR关闭。

@github-project-automation github-project-automation Bot moved this from Todo to Done in ArkTS Oct 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants