mprocs; Thorium; VS Code Remote Debugging

(Sadly, this is not about any browser port of the EPIC game series)

I thought it might be useful to describe part of the setup I use when working with JavaScript in a web browser context. Knowing JavaScript and the inner workings of various frameworks is only half the battle when it comes to creating something that you intend to use personally or release to the world. Being as productive as possible, and having access to the right tools in the right places can make a big difference in terms of efficiency and also whether you’re having fun or being frustrated.

Thorium

We’ve covered this browser before, so I won’t belabor this additional nudge to use Thorium for web development projects. I’m not a fan of using my everyday browser (it’s still Arc, but it applies to any browser I might switch to as my daily driver) for cranking on web projects. Even if I were to create and use a separate profile, use incognito mode in the startup config, or launch a completely separate instance, I still prefer a full separation of concerns.

Thorium is blazingly fast, has all the evil stuff Google keeps attempting to shove into Chrome disabled, and is sometimes even ahead of the Chrome stable releases.

mprocs

In web projects, there is often the need to have some background server running, be able to run some commands, launch a debugging browser, etc. You command line jockeys likely have some idioms you use to make those operations efficient to at least some degree. Let me toss mprocs into the mix for you.

This utility lets you runs multiple commands in parallel and shows output of each command separately. You can configure with a list of commands to run and also perform certain tasks on startup, but it has a superpower when it comes to web projects that center around a package.json.

One possible field in the package.json is scripts, which you can use with npm run. By starting up mprocs with the --npm flag, it will read the objects in this field and create a menu for you. An example of this is in the section header. From there you can start, stop, inspect, etc. any of the commands. You can even make one of the commands bash or vim and use them in the viewer pane.

For example, in an Observable Framework project you may want to clean the cache, start the dev server, and fire up a Thorium in incognito mode with a debug port and local profile:

"scripts": {
  "clean": "rimraf docs/.observablehq/cache",
  "build": "rimraf dist && observable build",
  "dev": "observable preview --no-open",
  "deploy": "observable deploy",
  "observable": "observable",
  "bash": "/usr/bin/env bash",
  "thorium": "/Applications/Thorium.app/Contents/MacOS/Thorium --incognito --disable-extensions --remote-debugging-port=9222 --user-data-dir=remote-debug-profile http://localhost:3000"
	}

Now you can do all that with a menu and have output in self-contained viewer panes.

The section header shows Thorium is open, the Framework dev server started (with logs from that in the viewer pane), and even a Bash session open.

mprocs can also listen on TCP port for remote commands, and has many other features that are explained pretty well in the README.

A nice feature of the Thorium config I use is that you get a remote-debug-profile folder in your working directory (make sure to add that to .gitignore!) so you can inspect the cruft anything leaves behind.

VS Code Remote Debugging

I’m still stuck in VS Code land thanks to the lingering cognition issues (thx, again, covid), but am at least working to migrate to VS Codium.

While I like using Developer Tools for Network and Element poking, I really dislike using it for interacting with JavaScript. It’s a terrible experience in every browser.

VS Code has a pretty nice “remote javascript debugger” experience, and you can customize a .vscode/launch.json to be named a certain way. Here’s a simple launch.json for a basic JS app config:

{
  "configurations": [
    {
      "name": "Attach to Browser",
      "port": 9222,
      "request": "attach",
      "type": "chrome",
      "webRoot": "${workspaceFolder}"
    }
  ]
}

Common options include:

• type: Specifies the type of debugger to use (e.g., node, python, cppdbg, chrome, etc.).
• request: Indicates whether the debug session will launch a new instance of the program or attach to an existing one.
• name: A human-readable name for the configuration, displayed in the debugging start configuration dropdown.
• program: Specifies the path to the program to be debugged. Often used with languages like Python and C++.
• args: An array of strings representing command-line arguments to pass to the program when it starts.
• cwd: The working directory of the program being debugged.
• env: A set of environment variables to add to the process.
• preLaunchTask: A task to run before the debug session starts.
• skipFiles: An array of file patterns to skip when debugging.

For other projects (say, a Golang one) there are even more advanced configuration options:

• env: A set of environment variables to add to the process.
• envFile: Specifies a path to a file containing environment variable definitions.
• cwd: The working directory of the program being debugged.
• preLaunchTask: A task to run before the debug session starts.
• postDebugTask: A task to run after the debug session ends.

There’s lots more info in the official docs.

The section header shows some console.log output, and you also get a fancy REPL that’s attached to Thorium where you can interact the same way you would in the Developer Tools console.

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev ☮️