Ansie

Ansie is a rich-text terminal rendering package that uses html-likemarkup instead of complicated terminal codes to generate its output.

I started this package out of frustration of not having a relatively simple way tooutput rich text without relying on direct terminal codes which is
difficult to parse with the human eye. Yes, there is
chalk butI was hoping to have something that would allow for easily updating the
look and feel without imperative programming required.
Ink isneat but it relies on a heavy-handed approach for layout (it uses a
rust-based layout engine for determining the layout of flexboxes - super
cool, but not what I wanted).

With Ansie, there are no dependencies for the library - not evenchalk. It uses PEGJS to build a parser that will read an xml-based
string and translate that into terminal codes.

For example:

1<h1 bold marginBottom="1">My Console App</h1>
2<h2 fg="gray" marginBottom="1">A little something I wrote</h2>
3<p marginBottom="1">
4  In order to used this app, do the following:
5  <li bullet="*" marginBottom="1">Create a config file</li>
6  <li bullet="*" marginBottom="1">Run the utility with the -h flag</li>
7  <li bullet="*" marginBottom="1">etc...</li>
8</p>

This feels better to me, as a web developer than the same thingwritten out with terminal codes:

1^[[1mMy Console App^[[22m
2^[[90mA little something I wrote^[[39m
3In order to used this app, do the following:
4*  Create a config file
5*  Run the utility with the -h flag
6*  etc...

As I play with the grammar and the compilation I’m learning a lotabout the intricacies of parsing and rendering a declarative langauge
like HTML. Decisions like whether to make the language more terse and
sacrifice consistency is a big one. Another one is what to do with the
“space between” declarations. Do you interpret them as-is (e.g. space
and newlines) or do you force the user to explicitly define them. In the
end, I have a feeling this will be an option, but the decision is one
I’m sure was made a long time ago in the HTML realm: be explicit unless
you use the
<pre>. Another interesting option that Iwill probably add in the near future.