refactor: replace apex-ls with lightweight SFDX class finder#691
Open
jjocoulter wants to merge 23 commits into
Open
refactor: replace apex-ls with lightweight SFDX class finder#691jjocoulter wants to merge 23 commits into
jjocoulter wants to merge 23 commits into
Conversation
…into bug/go-to-with-inner-class-params
lukecotter
changed the title
- add SfdxProjectReader/SfdxProject/VSWorkspaceManager to index sfdx-project.json classes, dropping the @apexdevtools/apex-ls dependency for faster go-to in large projects - strip namespace/System qualifiers on both sides of getMethodLine so methods with fully-qualified logged param types resolve - expose Context.workspaceManager (replacing workspaces) and route OpenFileInPackage through the new finder - add RelativePattern/findFiles/asRelativePath to the vscode test mock and drop the dead src/__mocks__/vscode.ts
…ching - add OpenFileInPackage suite (was 0% covered): symbol parse → find → open flow, not-found and non-exact-match error paths, and line/character positioning - add ApexSymbolLocator cases for System./namespace-qualified and source-side-qualified params, plus the no-parentheses early return - extend the vscode test mock with Selection/ViewColumn (needed to exercise showFile) and a null-namespace VSWorkspace grouping case
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📝 PR Overview
Main (#703) now ships the core "go to definition" fix for Apex symbols — inner-class resolution, constructor support, and character-precise positioning on
@apexdevtools/apex-parser5.x. This branch has been merged up to main, and its scope is now narrowed to the improvements main does not have:@apexdevtools/apex-lsdependency, replacing it with a lightweight in-repo class finder (SfdxProjectReader+SfdxProject+VSWorkspaceManager) that readssfdx-project.jsonand indexes**/*.cls..clsfiles match a symbol (main only disambiguates per workspace).getMethodLine: stripsnamespace./System.qualifiers (main strips only the outer class), so go-to resolves methods with fully-qualified logged params likeMyClass.doWork(System.List<Account>).🧩 Type of change (check all applicable)
🔗 Related Issues
resolves #834
✅ Tests added?
📚 Docs updated?
Anything else we need to know? [optional]
The original inner-class go-to fix that motivated this PR was independently delivered on main via #703, so that work has been dropped here to avoid duplication; only the apex-ls removal, finder, and qualified-parameter matching remain.