Idea: Add new commands to the plugin (data import/export, getting debug logs...)

[ognjen-vuceljic]

Hi @xixiaofinland ,

hope you're doing well today.

Just an idea - it might be good to consider adding more options to the plugin that can be triggered via hotkeys, in the same way as current ones do.

The commands that came to mind:

sf data import/export

forcedotcom/cli#2738

Sounds like Salesforce has invested some resources in improving those commands, so we now can pull more than 2 levels of child object data, plus handle >200 records (they will be split into batches), and much more as described in the link above.

Data export/import might be useful when we need to ensure that necessary data needs to be passed over from one environment to another.

---

sf apex get log

There could be some interesting use cases here in sf apex get log command.

For example, we could fetch the latest generated log from the org by running sf apex get log --number 1 -o target_org, or pass the --log-id as parameter.

We could easily run those commands in terminal outside of plugin, but just throwing out an idea here for brainstorming, to see if this is something that makes sense, and is worth investing time in.

---

Bonus question (nice to have):

• some sf commands, such as sf apex get log command, generate logs that are color-coded, which is quite useful for visualizing results

On the other hand, running anonymous apex comes with the same result structure, but no highlighting

Is this something we can standardize, so that printed commands are color coded (e.g. they have the filetype set to log, or something that would have syntax highlighting enabled).

Thanks!

[xixiaofinland]

Hi @ognjen-vuceljic,

For those commands, they can be easily defined by users separately as described here. It's hard for me to decide what should be part of the plugin or not. Maybe when I have the need or the plugin has more log-related features, I can add them into the plugin.

Speaking of the colored Salesforce log, yes, in case users retrieve and view them locally, it makes sense to have syntax highlight.

It might be a good idea to add a tree-sitter parser for Saleforce log, and give it a file type in this plugin.
Alternatively, we can use reg-ex to parse since the text pattern is relatively simple.
I'm more in favor of creating a tree-sitter parser, much more interesting :). But it will take some dedicated time.

Thanks again for sharing all your thoughts and the bug feedback. I won't have the drive to implement the sign icon feature without your support. I added you into the contributor list 😄 hope you don't mind. (Because markdown doesn't show github default profile icon properly, you don't have it there....

[xixiaofinland]

@ognjen-vuceljic

How do you use the log locally? More context on this LinkedIn Post: https://www.linkedin.com/posts/xixiaofinland_salesforce-activity-7224647096610492416-hBEN?utm_source=share&utm_medium=member_desktop

[ognjen-vuceljic]

Thanks @xixiaofinland

I usually download the log locally, and use one of 2 things in VS Code:

• Replay Debugger (which gives me a proper "Debug" environment, with breakpoints, etc.)
• I open the log, and use another extension called "Text Power Tools" which gives me the quick, nice filter ability, so I can easily focus on debug logs, or entry statements, or any line which contains a particular keyword

One thing I think would be extremely useful is highlighting the scope of a particular method inside log.

For example, pairing METHOD_ENTRY line with METHOD_EXIT line somehow, so that we understand when a particular method execution started, and when it finished.

Please see the example below:

This is a simple example, but it allows us to understand when the execution details of DirectoryHeadingUpdate method - when it started, execution details inside, and when it was completed.

The tricky part is when one method calls another, which adds call invocations into a stack.

I think parsing the log as TXT file with some sort of fuzzy finding and searching would be a great start. For example, searching for lines that contain |DEBUG| inside would filter out only the lines with that search param, and leave out the rest.

Hope this makes sense as a starting point :)

[ognjen-vuceljic]

@xixiaofinland I like the idea of sf apex tail log | grep 'hello

Could you, please, share some examples how you use it?

I do structure my debug statements in a way that clear ticket/JIRA identified is added, which makes search easier - but the issue is that those statements are scattered among multiple different log files, which can be quite big when we have queueables, future handlers, etc.

Any examples of usage would be much appreciated :)

[xixiaofinland]

This can be answered by GPT, pasted below.

We insert System.debug('hello:' + variables); in the code and execute the code. Any log lines include hello keyword will be displayed, others are filtered out.

The command sf apex tail log | grep 'hello' is used to monitor Salesforce Apex logs in real-time and filter them for lines containing the word "hello". Here’s a breakdown of what each part does:

sf apex tail log: This part of the command uses the Salesforce CLI (sf) to stream the Apex debug logs in real-time.
|: The pipe symbol (|) is used to take the output from the previous command (sf apex tail log) and pass it as input to the next command.
grep 'hello': This part of the command filters the streamed log output to show only the lines that contain the word "hello".
In summary, this command is useful for developers who want to monitor live Apex logs from Salesforce and focus on specific log entries containing the keyword "hello".

[xixiaofinland]

Thanks for sharing. Yes, once the parser is ready, this will be automatically supported.

I think parsing the log as TXT file with some sort of fuzzy finding and searching would be a great start. For example, searching for lines that contain |DEBUG| inside would filter out only the lines with that search param, and leave out the rest.

[xixiaofinland]

Nvim-treesitter now has sflog parser merged. nvim-treesitter/nvim-treesitter#7018

Update nvim-treesitter plugin to latest and add sflog parser like here

I will add this filetype into sf.nvim soon @ognjen-vuceljic

[xixiaofinland]