You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current Extensions today the LWC components know about available Apex AuraEnabled methods thanks to Type Declaration (d.ts) files created by the Apex extension, I believe the Apex Language Server compiled JAR specifically.
I would like to recommend this be moved to the LWC plugin and added to the open source code.
I believe the decision to have the Apex Lang Server handle this task is because it has the language parser inside of it. If we moved to the LWC extension then it would need something to parse the Apex files so it can discover the AuraEnabled methods that it should generate types for. You could use Regular Expressions but I personally wouldn't wish for more hit-and-miss RegEx in my life.
I would put forward the tree-sitter-sfapex library for this job. It has WebAssembly compiled and ready to go web-tree-sitter-sfapex or you can use the C code directly. I would suggest the WebAssembly is more than fast enough and even on projects with hundreds of class files only takes a few seconds to process all the class files.
This would be a big shift and I'd like to take on some of the development work if the team is agreeable to exploring this premise. I have a demo VSCode extension that can already do this and monitor Apex class files for change to keep the definitions up to date. I'm sure the code will need some refinement.
As far as what can be done open-source. Upgrading the LWC extension to handle this shouldn't be a big deal, like I said I already have a lot of this work ready for demo purposes. I don't know this code base well enough and would likely need more hand-holding to make it fit the existing system. Changing the Apex Language Server so it stops managing the files will be something that can't be done in the open and would just need the compiled JAR for the Apex Lang Server changed.
Let me know if the team is open to this and we can discuss further.
Making this change not only recreates the existing files but makes it much easier to add things like map files so features like "Go to Definition" in VSCode actually takes you all the way to the Apex files. Resolving some open issues (#4684, #4990, & W-12553326) I already have demos of this working that we can review.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
In the current Extensions today the LWC components know about available Apex
AuraEnabled
methods thanks to Type Declaration (d.ts
) files created by the Apex extension, I believe the Apex Language Server compiled JAR specifically.I would like to recommend this be moved to the LWC plugin and added to the open source code.
I believe the decision to have the Apex Lang Server handle this task is because it has the language parser inside of it. If we moved to the LWC extension then it would need something to parse the Apex files so it can discover the
AuraEnabled
methods that it should generate types for. You could use Regular Expressions but I personally wouldn't wish for more hit-and-miss RegEx in my life.I would put forward the tree-sitter-sfapex library for this job. It has WebAssembly compiled and ready to go web-tree-sitter-sfapex or you can use the C code directly. I would suggest the WebAssembly is more than fast enough and even on projects with hundreds of class files only takes a few seconds to process all the class files.
This would be a big shift and I'd like to take on some of the development work if the team is agreeable to exploring this premise. I have a demo VSCode extension that can already do this and monitor Apex class files for change to keep the definitions up to date. I'm sure the code will need some refinement.
As far as what can be done open-source. Upgrading the LWC extension to handle this shouldn't be a big deal, like I said I already have a lot of this work ready for demo purposes. I don't know this code base well enough and would likely need more hand-holding to make it fit the existing system. Changing the Apex Language Server so it stops managing the files will be something that can't be done in the open and would just need the compiled JAR for the Apex Lang Server changed.
Let me know if the team is open to this and we can discuss further.
Making this change not only recreates the existing files but makes it much easier to add things like map files so features like "Go to Definition" in VSCode actually takes you all the way to the Apex files. Resolving some open issues (#4684, #4990, & W-12553326) I already have demos of this working that we can review.
Beta Was this translation helpful? Give feedback.
All reactions