@pfaciana good question, I tried creating a symlink for heidisql and notepad++ and it kinda worked. I had both of them already installed before using Laragon.
So I deleted {laragon}/bin/heidisql, and created a symbolic link in its place (using Windows command prompt, I cd'd into {laragon}/bin, then ran mklink /D heidisql "E:\Software\HeidiSQL") and now when I click "Database" from Laragon's main window, I see it's running the HeidiSQL from outside Laragon (I knew because Laragon's HeidiSQL and my HeidiSQL are on slightly different version numbers). Although it still brings up Laragon's HeidiSQL database connections, not sure why.

If there's a better way I'd like to know about it too.

It actually comes with Git pre-installed. Notice the folder {laragon}/bin/git (where {laragon} is wherever you installed laragon).
If you open up terminal and type git --version and return, what do you see?

This tutorial is for setting up WordPress in Laragon so you can test patches from WordPress Trac.

Prerequisite: you'll need Laragon WAMP, not just Laragon Portable. You'll need to run node and npm.

Create Development Site

Video: https://drive.google.com/file/d/12Y-7QRUpA6V1207fCDvxxG6kmgyRipY0/view

1. Open Laragon.
2. Click Menu -> Quick App -> Blank. Name it "wpdev"
3. Click "Terminal", and in the terminal type git clone git@github.com:WordPress/wordpress-develop.git wpdev and then enter (or git clone https://github.com/WordPress/wordpress-develop.git wpdev and enter your GitHub username and password)
4. Copy {laragon}/www/wpdev/wp-config-sample.php to wp-config.php, and enter change the database name to be wpdev, and user to be root, with blank password
5. Still in terminal, type cd wpdev, enter, then npm install && grunt build
6. If using nginx, find{laragon}/etc/nginx/sites-enabled/auto.wpdev.conf (if using apache, use that instead) and remove auto. from its name.
7. In that file, find the line that starts with root (or sometimes define ROOT), and add build/ onto it.
8. In laragon, click "Stop All" and "Start All'. Now your copy of the development version of WordPress should be running at wpdev.test.

Apply Patches

1. Find the ticket from trac.wordpress.org that you want to apply, and take note of its ticket number
2. From {laragon}/www/wpdev/, run grunt patch:{ticket-number}. Eg if you wanted to apply the first patch from [Trac ticket 43443](https://core.trac.wordpress.org/ticket/43443), you would typegrunt patch:43443`, and then it would ask you which one of the uploaded patches you'd like to apply.
3. After applying the patch, you should run grunt build again (to re-sync the changes made to the src directory to the build directory)
4. When you're all done testing and want to undo the patch, run git checkout .
   See https://make.wordpress.org/core/handbook/tutorials/working-with-patches/#applying-a-patch for more information.

@Michael-Chean that's a mystery alright. You should probably create a new issue (feel free to ping me and I'll try to help)

Since laragon 3.1 you shouldn’t need to do WordPress’ database configuration anyways.
What version of laragon did you install?

@laragonani I made a 2 minute video showing exactly this. https://www.youtube.com/watch?v=DXv4wlzbaNw&t=2s

@leokhoa and make sure you close the terminal windows after switching node version, and open a new one.

@danieliser kinda a good question. As I understand it, it should really toggle xdebug on and off. So it sounded great but I haven't got it to work yet. (To enable xdebug, I followed the above instructions; and to disable it, I remove the xdebug lines from my php config file, save, and restart Laragon)
You should probably start a separate topic with your question IMO

@goodness ok great!

Yeah, I think when folks say they don't need to use Docker, they meant they didn't need to use it for local development. I haven't actually setup a site with Docker yet, but I understand it's great for setting up the exact same environment between production, staging, and development.

I personally have enjoyed developing with Laragon on Windows for development because it's much faster, simpler, and pretty feature-rich. (Eg using ngrok has been handy). Especially when, as I understand it, in order to get Docker to work, I'd need to run it inside a virtual machine, and from my experience virtual machines are pretty slow and sometimes have some intricate problems. (What got me to move from primarily developing on a Virtual Machine was npm in a virtual machine with a Windows host machine was giving me lots of grief).

BUT, Laragon certainly doesn't give you an identical environment between development, staging and production like Docker can. So I don't think its a complete replacement.

hi @goodness, I'm not sure if I understand what you're asking.

If you're asking if it's a good idea to use Laragon to run a production app (eg a live website users will be visiting), then no it's not a good choice. Mostly because Laragon only runs on Windows, and nearly all production servers use Linux. So not a good idea to use Laragon for a production app, nor do I know how you would do it.

But maybe you're asking if it's a good idea to develop an application on Laragon before deploying it to a live server somewhere. I think it's fairly good for that, especially if you make sure the version of the programming language in Laragon matches what you'll be using on the database server (eg both using PHP 7.1) and all the other software versions match up (eg both using Apache for the webserver, MySQL for the DB, etc).
However, most likely the server you'll be deploying to will be running on Linux, whereas Laragon only works on Windows, so there will be a few differences in how the app runs. (Eg, Windows directory separator is a backslash instead of a forward slash, and the filesystem is NOT case-sensitive.
So if you're doing using Laragon to DEVELOP an app, you probably just want to use it for initial development, then put your app on a staging server which more closely resembles your production server (where you'll probably notice a few discrepancies) and only then deploy your app to the production server.

xip.io and nip.io allow you to have a subdomain multisite WordPress site without needing to add a DNS entry to your hosts file for every subsite.
Here's how:

1. Create a new WordPress site using Laragon's Quick App. Let's say your new site's name is "mysite.test"
2. Install WP CLI
3. Open Laragon's Terminal and run wp search-replace "mysite.test" "mysite.127.0.0.1.nip.io" --all-tables (or you could set it to xip.io, I haven't seen any difference).
4. Rename laragon/etc/nginx/sites-enabled/auto.mysite.test.conf to mysite.test.conf, and change server name line to server_name mysite.127.0.0.1.nip.io *.mysite.127.0.0.1.nip.io; (or if you're using Apache, change the ServerName to be mysite.127.0.0.1.nip.io and ServerAlias to be *.mysite.127.0.0.1.nip.io).
5. In Laragon, click "Stop All" and then "Start All". Visit mysite.127.0.0.1.nip.io. It should be your site.
6. Enable WordPress multisite, choosing the "sub-domain" option.

Now you can create any subdomain you want on your site, without ever needing to touch your hosts file again. Enjoy!

@leokhoa regarding implementing this in a procfile:
how would I execute the equivalent of "Menu -> Quick App -> Blank. Name it "wpdev""?
Executing the terminal commands and editing files seems straightforward (just separate them all by &).
I'm also not sure if I can get user input about what name they'd like for the WP development site.

@leokhoa yeah ok I'll read up on Procfiles. Maybe having a command to create a WP development site would be better than my earlier idea to create a fork of Laragon with everything pre-setup (see https://forum.laragon.org/topic/1044/laragon-for-wordpress-core-contributions/2). I'm afraid that would be more work to maintain, whereas having a command to download and set everything up would be more light-weight.

In Laragon, I go Menu -> Tools -> WildCard DNS -> How to Manage "WildCard DNS", then my browser opens to https://forum.laragon.org/topic/1014 but it says "Access Denied"

maybe I could use procfile to do everything under "Create Development Site"? Not familiar with that yet.

@pfaciana an alternative to MigrateDB Pro for doing a global find-and-replace on your WordPress database is using WP CLI's search-replace command (see the docs). I'm pretty sure wp search-replace "oldsite.com" "newsite.com" --all-tables will do. (Here's how to set WP CLI with Laragon)

@leokhoa I also found adding these two lines to my wp-config.php worked:

define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST']);
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST']);

(Got that from https://ngrok.com/docs#wordpress) Not sure why, but I actually didn't need any other plugin. 🙃

I think Laragon would be great for simplifying the process of setting up a dev environment for WordPress core contributing.
WordPress' recommended way of setting up a local development environment for contributing to WordPress core is pretty involved (see https://make.wordpress.org/core/handbook/tutorials/getting-started/#setting-up-your-development-environment) and I think Laragon could make it a lot simpler.
I was thinking of creating a fork of Laragon that:
-already has a WordPress site setup from the development repo (ie, git://develop.git.wordpress.org/)
-has phpunit setup
-runs npm install && grunt build && grunt watch on startup

This way, folks could just download this version of Laragon, and then start contributing code or testing Wordpress core patches, without so much hassle.

Any thoughts on how to implement this? I was thinking of:
-forking the github repo
-in the fork, create the site and database and commit them
-also add support for phpunit, and probably wp-cli while I'm at it

But is there a better approach?

Here's some instructions for installing WP CLI on windows: https://deluxeblogtips.com/install-wp-cli-windows/ which should help (I haven't gone through them all yet)

@leokhoa I found I also needed to add xdebug.remote_enable=1 to the php.ini file. Otherwise, those steps worked great.