Delve debugging

[symball]

Adds a debug sub command which in turn executes the wails app using delve waiting for a debugger session.

I would like to tidy the code up a bit further before marking this as ready after getting some feedback. It is quite messy because it was an investigation in to the workings of wailsv3 at the same time

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: e9866556-0788-4408-b102-ac1fe74b6ebb

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[symball]

Note that when you run debug wails won't appear to start. It will be waiting for you to connect to Delve before beginning execution. I will for sure add this as an option during the tidyup. for now

IntelliJ - Use "Run -> Add Configuration," choose "Go Remote," and specify the host and port.
CLI - Run dlv connect :2345 to connect a terminal client to a headless server.
VSCode - .vscode/launch.json with "mode": "remote" and "request": "attach"

[symball]

comment to link #5138 because Github is flakier than Winter snow these days

[leaanthony]

🔍 Triaged by Wails PR Reviewer - Awaiting Feedback

This PR has been reviewed and looks interesting, but I have some questions before proceeding:

1. You mentioned you'd like to tidy the code up further - is this PR ready for review, or still a work in progress?
2. What specific debugging scenarios does this enable that weren't possible before?
3. Are there any documentation or example updates needed?

Head Ref OID: 447cac24029c2fe98780b4caba00c09b31cf96f1

---

This comment serves as a signature that this PR has been triaged. Future runs will skip this PR based on the headRefOid.

[leaanthony]

Thanks for this PR! You mentioned in the description that you'd like to tidy up the code before marking it as ready. Please update the PR when it's ready for review, and consider adding tests and updating the documentation if needed.

[leaanthony]

I see you mentioned this PR is quite messy and you'd like to tidy it up before marking it as ready, and that you want to get some feedback first.

Could you share:

1. What specific areas you think need cleanup?
2. What aspects of the implementation you'd like feedback on?
3. Are there any concerns about the current approach?

Once you've addressed these and marked the PR as ready for review, I'll take another look.

[symball]

hey there, sorry about the delay in responding; been quite a busy chap! Scraping my mind a bit

The cleanup

In build/config.yml (generated asset) I was thinking it might be a good idea to programmatically implement the atterpac/ refresh definition. Currently, there are two configurations hardcoded in the yaml file, one for dev and then to support the debugging. It ties in to my next point but, for covering more options (such as start process without waiting for debugger) as is it would require more profiles and then more yaml file processing logic. There was a PR that got merged which i would incorporate in to the watch part, this is the cleanup part

Feedback requested

This was really just asking people to make sure it isn't broken on different setups and secondly if there are any extra options people would want to include such as wait on debugger, debugger port, and other Delve options

Concerns

Really just about the way the refresh spec is pieced together from a maintainability point of view. i will try to make some time to spend with v3 in about a week and can happily implement the changes and try to help with other stuff

[leaanthony]

Thanks for working on this! Debugging support would be a valuable addition to Wails v3.

You mentioned that you'd like to tidy up the code before marking it as ready. When you've done that, please update this PR with:

1. Cleaned up code as you mentioned
2. Detailed description explaining:
   • How the debug subcommand works
   • What the user experience is like
   • Any prerequisites or setup required
3. Testing information:
   • How you've tested this
   • Instructions for others to test it
4. Completed checklist from the PR template
5. Link to an issue if this addresses a feature request (if one exists, please link it; if not, consider opening one first for discussion)

Feel free to ping me when you've updated the PR and I'll take another look!

Decision: COMMENT-AND-WAIT - Awaiting code cleanup and additional information

CC @leaanthony