Syntax Highlighting for code in the Phoenix (= Plug) debugger

Just created a very simple library that allows you to have syntax highlighting in the Phoenix debugger. Code here:


Adds support for syntax highlighting in the Phoenix debugger.

To use, replace the following line in your application’s endpoint:

use Phoenix.Endpoint, otp_app: :your_app

by the this line:

use PhoenixWithPrettyDebugger.Endpoint, otp_app: :your_app

No other changes are needed.

Happy hacking with a prettier debugging experience!

The highlighter supports elixir and erlang by default (so it can even highlight code in the cowboy modules). Internaly this project uses the makeup syntax highlighting library and you can add support for other languages by importing the appropriate lexers.

Example output:

Highlighting Elixir:

Highlighting Erlang:

Is this safe?!

This library simply defines an alternative to the default Phoenix.Endpoint module which is actually API compatible. We reuse as much functionality from that module as possible and only redefine the parts we need to add our new debugger. Becuase the debugger is only used in :dev and never in :prod

@tmbb Hmm … honestly I do not see why it’s a standalone library … If I remember correctly makeup is used even in ex_doc, so I do not see why it could not be a part of phoenix … Did you proposed this enhancement before? If so can you please link to such discussion for a reference, please?

The debugger is part of Plug and not Phoenix. I’ve proposed to add syntax highlighting to Plug here:

I think that instead of adding syntax highlighting to plug debugger is rather have a way of of setting a custom debugger in the Phoenix.Endpoint module (as my last message from that PR explains).

1 Like

Sorry, my mistake. I mean exactly what you wrote here:

(…) If we change the phoenix generators to include makeup as a :dev dependency, then most people will indeed have access to the improved debugger. (…)

Thanks! Now I can see the case …

Thanks @tmbb! If it makes your life easier, we could add a highlighter API to Plug.Debugger, where we call highlighter_module.highlight(snippet, min_line..max_line) . So your implementation has only to implement the highlighting bits. This way it is extensible but we don’t have to keep the makeup code in Plug itself. Would that help?

This is exactly what I had in mind …

(…) I don’t think that’s the way to go. I’d rather have a debugger module (with respective options) passed as an argument to use Phoenix.Endpoint, ... instead of hardcoding Plug.Debugger (…)

and that’s your answer.

I quoted those parts as I believe there are the most interesting for other people interested in this topic.

I have only one question …

That way people could use their own debuggers (a debugger with syntax highlighting, a debugger that replays the request with different parameters, a debugger that lets you update code in place, etc). That’s what my package does, it adds a completely new debugger (which is mostly copy-pasteed from the original Plug.Debugger ) which as a feature highlight the files. I only had to define a new PhoenixWithPrettyDebugger.Endpoint because Plug.Debugger is hardcoded in Phoenix.Endpoint 's __using__/1 macro.

Can you please describe if and how it’s possible to write said debuggers and have your syntax highlighting at the same time? From what I can see PhoenixWithPrettyDebugger.Plug.PrettyDebugger.Highlighter module is private (@moduledoc false), so you do not exposing it’s API, right?

Can you please describe if and how it’s possible to write said debuggers and have your syntax highlighting at the same time?

You just have to duplicate the functionality in your own debugger module, of course. I’m not interested at all in exposing any part of this as public API. Just copy and paste the relevant files into your own project.

1 Like

I’ve added some new capabilities to my debugger. You can now (using the debugger page) add breakpoints to a function in on any of the frames and replay the request handling with that breakpoint (and pry that breakpoint in IEx). You have to start your phoenix app

It’s not as useful as I though it would be (beam stack frames aren’t that awesome and they lose a lot of information), but its pretty cool. It can also serve as an example for other who might want to extend Phoenix’s debugger.

You can get it from github master.