DEV Community: Benjamin G.

CLI application with the Node.js Readline module (3/3)

Benjamin G. — Wed, 19 Mar 2025 09:12:55 +0000

Node.js version: 22.1.0.

Part one - the basics - is here: https://dev.to/camptocamp-geo/cli-application-with-the-nodejs-readline-module-48ic

Part two - going further - is here: https://dev.to/camptocamp-geo/cli-application-with-the-nodejs-readline-module-23-2ekg

Testing

A program is never complete without tests. In addition to unit tests, which are generally context-free, I tried to do a more global test. More or less an acceptance test for my CLI program. I was faced with two problems:

How to read my console.
How to simulate writing.

Read

To read what comes out of console.log, or its sub-layer stdout.write, it is by definition not possible to use readline. Otherwise, every output would be an input, which would be problematic. So we have to find a roundabout way. Here are two possibilities:

Add a “debug” mode and associated methods to store the logs somewhere for access in tests. For example, in an object, or in a file, and in this case why not with a second readline instance.
Overload “console.log” or “stdin.write” to redirect written values before continuing execution of the standard function. No need for a “debug” mode.

In my case, I used the second method. With vitest and its spyOn, it was easy and quite elegant, here's an extract:

import { test, describe, vi, beforeAll, expect } from "vitest";
import { stdin } from "node:process";
import { CliLearningCards } from "./cli-learning-cards.js";

const consoleSpy = vi.spyOn(console, "log");
const getLastLog = () => `${consoleSpy.mock.lastCall}`;
/** @returns n previous log */
const getReverseLog = (reverseIndex: number) => {
  const n = consoleSpy.mock.calls.length - reverseIndex;
  return `${consoleSpy.mock.calls[n]}`;
};
...

describe("Cli-learning-card", () => {
  beforeAll(() => {
    consoleSpy.mockClear();
  });
  ...

Simulate writing

In theory, it's simple. Here's a quick summary:

stdin is unique per process.
In my case, the test process is the same one running my program.
I can give stdin as input to my Readline interface.
And if I write stdin.emit('keypress', null, {name: 'enter'}), my program receives my “enter” event.

However, in my test, if I create a readline interface, and write rl.write(“a sentence”), it never reaches my program. Worse still, if I add:

// Inside my program 
getRl(): readline.Interface {
  this.rl;
}

// Inside my test
const mySoft = new MySoft();
mySoft.getRl().write(“hello\n”); // Does nothing :-(

And if I use it to write my test, it doesn't work.
On the other hand, and even less elegantly, if I add a function to my program to write directly:

// Inside my program
write(line: string) {
  this.rl.write(`${line}\n`);
}

// Inside my test
const mySoft = new MySoft();
mySoft.write(“hello”); // It works !!?

In this case, it works. It's not clean, but I can simulate writing from my test. And I currently have no idea why it works in this case, but not in the previous one. Comments welcome!

Debugging

It's easy to debug your application with node --inspect and a Webkit browser. On the other hand, seeing the results can be complicated if your program regularly cleans the terminal. If you don't understand the results displayed, I advise you:

Temporarily comment out your terminal-cleaning method.
Or redirect your “console.log” to a file.

Multi stream

Events

As I was using several readline interfaces, I sometimes couldn't understand why my application wasn't reacting to my events. Always remember that each instance has its own listeners, including streams of course.

Close events and stdin/stdout

If several of your streams are linked to stdin, don't forget to handle the stream stop events in each stream. If only one is not managed, the stdin/stdout streams will be cut, and all your readline interfaces will stop. So, if your program is active as long as your interfaces are active, then your program will stop if you forget to handle a stop event for one of your readline interfaces.

CLI and the “I” problematics

In CLI , there's the I for interface. And making a beautiful, modular, responsive, clean interface can take a lot more time than coding the logic of your program. Here are some of the difficulties you'll have to face:

It's all text, and only text. But the good news is that any character always takes the same space.
It may take two characters in a string to form a visual character.
Color is also some characters in a string, but does not affect the length of the printed text.
Users can resize their terminal at any time (node.js can handle that with events and stdout.columns, stdout.lines).

For a simple program, it's possible to manage these cases in a reasonable time. If you want to go further, I advise you to turn to external libraries. For example (this list is obviously not intended to be exhaustive):

Colors and text management: https://github.com/chalk/chalk and all the sub-librairies they have
Commands argument formatter and parser: https://github.com/tj/commander.js
Nice prompts and more: https://github.com/terkelg/prompts
Another prompt-and-more tool https://github.com/enquirer/enquirer
Advance CLI modules: https://github.com/chjj/blessed
Advanced CLI, but with React: https://github.com/vadimdemedes/ink

And many, many more. The aim here was to talk about Readline, which I think gives you a good basis for managing, understanding and using these CLI libraries, and creating your own program.

CLI application with the Node.js Readline module (2/3)

Benjamin G. — Mon, 03 Mar 2025 09:44:21 +0000

Node.js version: 22.1.0.

Part one - the basics - is here: https://dev.to/camptocamp-geo/cli-application-with-the-nodejs-readline-module-48ic

In the part one, I was able to go far using the question and the listener on('line', cb) methods from the Readline interface.

Going further

I currently have two limitations:

I can't display anything below the input line.
It's impossible to completely refresh the interface.

To compensate for this, I can use many of the commands and events from stdin, readline and Readline.Interface. I'm going to detail here the three major problems I encountered.

Clear the screen

If you want to build a complete CLI application, you probably want to be able to refresh your entire terminal to avoid polluting the screen with old questions and commands.

import readline, { createInterface } from 'node:readline';
import { stdin, stdout } from 'node:process';

const rl = createInterface({
  input: stdin,
  output: stdout,
});

const clear = () => {
  readline.cursorTo(stdout, 0, 0);
  readline.clearScreenDown(stdout);
};

let value = 0;
const printQuestion = () => console.log(`Add up! Add a number to ${value}:`);

const refresh = () => {
  clear();
  printQuestion();
}

const onLine = (line) => {
  const val = parseFloat(line);
  if (isNaN(val)) {
    console.log("Please, add a valide number")
    return;
  }
  value += val;
  refresh();
};

rl.on("line", onLine)
refresh();

The main innovation here is the direct import of readline and the use of readline.cursorTo and readline.clearScreenDown.

The first method moves the cursor to a given absolute position (column, row). Use readline.moveCursor for a relative position. The second deletes all characters after the cursor position.

This only works in a TTY (Text Terminal), which is our case with stdout and a direct file call from node.js.

Refresh or write after input

At one point, I wanted to add a time limit to my game. And I wanted to display the remaining time. So I added something like this (you can add it at the end of the previous script):

setInterval(() => {
  refresh();
}, 1000)

What's the problem? Well, the implemented clear function deletes everything. The error text is not in the refresh function, and will be deleted. And the text currently being written will also be deleted.

Please note that this is only visual. The line being written still exists and can be accessed with the line attribute of an instance of readline.Interface.

One solution is to be precise with readline.clearline. But this solution can quickly become unwieldy and doesn't solve a second complication: writing after the input line.

So I prefer to prevent stdin from displaying input characters, and display these characters myself, wherever I want.

import readline, { createInterface } from 'node:readline';
import { stdin, stdout } from 'node:process';


const rl = createInterface({
  input: stdin,
  output: stdout,
});

const clear = () => {
  readline.cursorTo(stdout, 0, 0);
  readline.clearScreenDown(stdout);
};

// To manage the text to print, store it into a map.
const content = new Map();
let value = 0;

const updateQuestion = () => {
 content.set("question", `Make additions! Add a number to ${value}:`);
};

// Print the whole stored text content.
const printContent = () => content.forEach(text => console.log(text));

// Print the line as well as it's deleted by the clear.
// Normally we have a blinking caret to indicate the position
// Simulate it as well (psoition and representation).
let blinkWhite = true;
const txtbgWhite = "\x1b[47m";
const txtReset = "\x1b[0m";
const printInputLine = () => {
  const caret = blinkWhite ? `${txtbgWhite} ${txtReset}` : " ";
  const chars = rl.line.split("");
  chars.splice(rl.cursor, 0, caret);
  console.log(chars.join(""));
};

const refresh = () => {
  clear();
  printContent();
  printInputLine();
}

const onLine = (line) => {
  const val = parseFloat(line);
  if (isNaN(val)) {
    content.set("error", "Please, add a valide number");
    return;
  }
  content.delete("error");
  value += val;
  updateQuestion();
  refresh();
};

// onListen to keypress to clear the line and handle it by ourselves.
// As we manage the blinking caret, we also have to refresh on cursor move.
const onKeypress = (letter, key) => {
  if (!letter && key.name !== "left" && key.name !== "right") {
    return;
  }
  // Clear the input line
  readline.clearLine(stdout, 0);
  refresh();

};
stdin.on("keypress", onKeypress);
// To unlisten
// stdin.off("keypress", onKeypress);

rl.on("line", onLine)
updateQuestion();
refresh();

setInterval(() => {
  blinkWhite = !blinkWhite;
  refresh();
}, 500)

We need to be able to display the input text ourselves. The “printInputLine” function takes care of this and also simulates the “blinking caret” essential for the user to edit the line. There's no need to store what's written. “Rll.line”, from readline.Interface, takes care of this.

The final step is to hide the default write line. To do this, you can listen to the "keypress" event on stdin directly. If a letter is pressed, or the user navigates to the left or right of the text, the text line is deleted, and the text updated.

stdin.on(“keypress”, callback) is also very useful for simply navigating through a menu. For example to select an option from a list of options, as shown here: https://github.com/ger-benjamin/cli-learning-cards/blob/1.1.0/src/scenes/list-select.ts

And the default blinking caret?

In the example above, we're simulating the “blinking caret”, or cursor, but there's nothing to stop your terminal's default caret from blinking. With the current implementation, we have two blinking caret, which is confusing for the user.

It is possible to simulate inputs by the user. For example (taken directly from the Node.js documentation):

rl.write('Delete this!');
// Simulate Ctrl+U to delete the line written previously
rl.write(null, { ctrl: true, name: 'u' });

It's just like pressing “ctrl” + u in a terminal.

Here, rl is a “readline.Interface”. It's possible to use stdout.write directly, but the “ctrl + u” combination will have to be written directly into its ANSI code.

I didn't find (and didn't look too hard for) the keyboard combination that would allow me to hide the “blinking caret”. But I did find its ANSI combination. Executing process.stdout.write(”\x1B[?25l“); hides the cursor.

This is a combination directly dedicated to the terminal. At this point, you might be able to understand for yourself how the “readline.clearLine” or “readline.cursorTo” functions are working.

As hiding the cursor directly affects your terminal, don't forget to make it appear again at the end of your Node.js process. Even in case of error! To do this, make sure your program always executes the command process.stdout.write(“\x1B[?25h”);, in order to display the cursor again.

Part three - advanced notes - is here: https://dev.to/camptocamp-geo/cli-application-with-the-nodejs-readline-module-33-ka9

CLI application with the Node.js Readline module (1/3)

Benjamin G. — Mon, 24 Feb 2025 09:48:26 +0000

Node.js version: 22.1.0.

Using Node.js to create your own scripts works well. And if you're used to using Javascript or Typescript, writing your scripts will be very quick. But while I was using k9s (a CLI manager for kubernetes), I wondered if it was possible to make such a tool with Node.js. Without going that far, I embarked on a small project to analyze the Readline module in Node.js. This is to be used both in scripts and in more complete CLI applications.

I’m going to detail the difficulties I encountered in using Node.js Readline and creating a basic CLI application. (And not the module itself, read the doc!) I've put together all the solutions to the problems I encountered right here, which should give you a comprehensive guide to understanding and avoiding the same complications.

This blog is longer than initially expected and will be divided into three parts:

Part one - the basics - is below.
Part two - going further - is here: https://dev.to/gerbenjamin/cli-application-with-the-nodejs-readline-module-23-2ekg
Part three - advanced notes - is here: https://dev.to/camptocamp-geo/cli-application-with-the-nodejs-readline-module-33-ka9

About my test project.

To learn new terms in another language, I've often used paper cards. On one side there's a word in one language, on the other side the word in the other language. The exercise is perfect for this project. The application has to display one side of a “card”, the user responds, validates the answer, and moves on to the next card. In the course of the project, I added “game” features such as clues, lives, time, etc. to the application.

I've used as few external libraries as possible in order to fully understand readline's capabilities and limitations.

You can access the project in question here: https://github.com/ger-benjamin/cli-learning-cards/tree/1.1.0

The basics

Readline “question”

To question the user, my first approach was to use Readline's question method.

import { createInterface } from 'node:readline';
import { stdin, stdout } from 'node:process';

const rl = createInterface({
  input: stdin,
  output: stdout,
});

rl.question("What's your name?\n", (answer) => {
  console.log(`Hello ${answer}`);
  rl.close();
});

The result is as follows:

> node test.mjs 
What's your name?
Zorro
Hello Zorro

And it works well... but it's not very flexible when it comes to the UI, as we'll come back to later.

Note that I used createInterface from node:readline. The equivalent is possible with node:readlinePromise, but instead of a callback, you'll use an await to get your response. The advantage of callback here is that I don't have to wait for the response to execute other things.

I start by creating a readline interface. I bind to it the standard input (stdin, the keyboard), and the standard output (stdout, the terminal) of the process. This would also make it possible to link input and output to a file, for example.

As the interface is an instance, it is possible to have several instances. This may be practical (we will see that later), but not necessarily with rl.question.

Readline stream

Note that createInterface creates a stream (duplex). And since in my example it's linked to stdin and stdout, there's no reason for the stream to stop on its own. This allows me to keep the process active.

After printing my response via a console.log, I close the stream to exit the process. In this case, rl.pause() would amount to the same thing, since the stream here is keeping the process alive.

Since I'm using readline as a stream (and not as a promise), I have access to certain events. So I can perform the same script with rl.(“on”, (line) => callback);

import { createInterface } from 'node:readline';
import { stdin, stdout } from 'node:process';

const rl = createInterface({
  input: stdin,
  output: stdout,
});

rl.on("line", (line) => {
  console.log(`Hello ${line}`);
  rl.close();
});

console.log("What's your name?");

A subtle difference here is that I write my question with console.log, and console.log automatically adds a line break. This was not the case with rl.question, which in my case is based on stdout.write. This kind of difference is listed here for example: https://www.geeksforgeeks.org/difference-between-process-stdout-write-and-console-log-in-node-js/

This way of writing the code is a little more flexible, since it's not necessary to call rl.question after each entry. But this is not exclusive, and you can mix the two:

import { createInterface } from 'node:readline';
import { stdin, stdout } from 'node:process';

const rl = createInterface({
  input: stdin,
  output: stdout,
});

const printQuestion = () => console.log("What's you name?");

rl.on("line", (line) => {
  console.log(`Hello ${line}`);
  rl.close();
}).on("SIGINT", () => {
  rl.question("Are you sure you want to exit?\n", (answer) => {
    if (answer.match(/^y(es)?$/i)) {
      rl.close();
    } else {
      printQuestion();
    }
  });
});

printQuestion();

Here, a confirmation with question is requested before closing the process.

Key concepts

A few key points on the basic principles:

Readline.createInterface allows you to create stream or promise instances of Readline.Interface (Be careful not to accidentally mix the two).
An open stream keeps the process alive.
Stdin and stdout are linked to one process.
Stdin and stdout are unique to a process.
rl.question() or rl.on(‘line’, cb) allows you to read the input.
Console.log, or stdout.write, or rl.write, allows you to write to the output.

Part two - going further - is here: https://dev.to/gerbenjamin/cli-application-with-the-nodejs-readline-module-23-2ekg

Part three - advanced notes - is here: https://dev.to/camptocamp-geo/cli-application-with-the-nodejs-readline-module-33-ka9

End to end testing Canvas element

Benjamin G. — Wed, 22 Mar 2023 12:42:23 +0000

Canvas (Maps, charts, etc...) elements have no DOM element to select, therefore they are hard to test using regular testing framework/methods. Still we have some possibles solutions:

It's possible to test the values that serves to build the Canvas.
It's possible to visually check the differences between the current version of the canvas and a previous one.

Here's a summary about (recent) solutions I've tested.

Test values of the Canevas

Output results of the canvas (what you want to test/know) in a data-attribute, in the dom.
- You can select this attribute and make a test on it.
- That pollutes the DOM but it works and it's relatively lightweight if you don't test every values but only the keys ones.
Output results in a dedicated not-visible component
- You can select this attribute and make the test on it.
- Ugly, but regarding idea n°1 it gives you a better separation between test and user's code.
- Possible to enable this component only in tests (like with an url param "&tests=true").
Using visual comparison
- ✅ Most trustworthy way to make "real e2e".
- ❌ Easy to install, hard to set up properly.
- ❌ Very sensible to changes.

Wait on the canvas to be fully rendered

Useful typically when you want to test interaction with you Canvas.

Depends on the library, you may have a "render-ready" event or something like that.
Generally, if you wait on the values that create the canvas (see section above), then the canevas is ready.
💡Images are slow to be loaded, watching and waiting on icon/images request can be a good idea.

Visual comparison systems

Generally too sensible. Minor changes break a PR, even with a good tolerance.
Snapshot depends too much on the environment. Local testing could give you not the same results as CI testing.
- ⚠ That could make reference images complicated to generate or makes not possible local testing.

If you want to install a tool, instructions are on their website, and a lot of tips can be found on dev.to 😎

Chromatic

https://www.chromatic.com

I've only experienced it with the whole page / example page / storybook page. I don't know if it's possible to focus on a specific element.
Works well, relatively easy to set up.
Can be a check in your Github's PRs, linked to a page to review the change.

Cypress visual regression plugins

There are multiples plugins:
https://npmtrends.com/@applitools/eyes.cypress-vs-@cypress/snapshot-vs-cypress-image-diff-vs-cypress-image-diff-js-vs-cypress-image-snapshot-vs-cypress-plugin-snapshots-vs-cypress-visual-regression-vs-cypress-visual-testing-vs-happo-cypress

Generally based on Cypress snapshot:

✅ It allows you to snapshot an element: cy.get('canvas').snapshot... and not the whole page!
✅ Easy to setup for most of the plugins.
😎 Most are open source
❌ A lot of plugins are old and only supported by a small community.
❌ Cypress strangely "zooms" into the component to snapshot, making it hard/impossible to have what you want.
❌ Works bad with high resolution (tried with 5120x2060)

Yes, visual comparison is the quicker way to test every settings of you Canvas. But that's only when the system is set up and doing that will give you head each. Also, rendering function should be already tested by the library that draws the canvas for you.

Think twice before to choose a way to test you code 😀

D3-Helper: Mini-library to quickly set up a D3 chart.

Benjamin G. — Tue, 23 Jun 2020 08:03:35 +0000

I'm not a native English speaker

To draw charts in a web-page, my favorite library is D3. Even if that's not the simplest library to draw charts, it's quite stable and I was always able to reach my aim with it.
But after some implementations of charts, and as D3 is not only made to draw charts, my project team has seen that some part of the implementation was quite repetitive:

We always have to draw or clear the SVG, with a fixed ratio.
We always have to manage a margins system.
In Cartesian charts, we always have to set an axis system.
We often have a title, a color, a font-size...

Also, I don't know why, I really don't know why, but it looks like that for D3, all examples are always a one-function-code. That's not handy to use nor to test it. Even if you don't mind about d3-helper, please dispatch your D3 code in multiple functions 😀

So we have decided to make this micro-library d3-helper.
The aim is to set up a base for charts easily, so then the final app can focus on the drawing relative to the data. It currently contains two classes:

A BaseD3ChartSVG class, to select, draw and clear the SVG, with a "chart" group inside depending on a margins system.
A CartesianChart class (that extends the BaseD3ChartSVG class), to (mainly) draw and manage axes (set scale, draw, clean) for a Cartesian chart. Supported data must be numbers, texts or dates.

Both classes define small methods that can be called independently and "summary" methods that call multiple methods (for standard uses).
Some methods were "restricted", but we finally decided to have almost everything public to maximize the flexibility. And we leave the encapsulation to the final app (and never mind for the 0.1k more of compile code).

In the examples below, I use node to install the d3-helper library and some additional D3 functions to play with my data.

I also use a static dataset "data" (an Array of Objects).

Draw a pie-chart

Directly taken from the d3-helper pie-chart example.

I start by creating a chart class that extends BaseD3ChartSVG, so this will be the BaseD3ChartSVG. That's more handy than to attach an instance of it to a variable. In the constructor, I set the path to the chart element to render the PieChart in. Also, I set a d3Pie basic function.

class PieChart extends BaseD3ChartSVG {
  constructor() {
    super('.chart');
    this.pie_ = d3Pie()
      .sort(null)
      .value(d => d.elevation);
  }
  ...

Then I want a draw function to draw my PieChart. I'll use the BaseD3ChartSVG to render the "generic part" of the chart: draw the SVG and set the margins.

  draw() {
    // Use BaseD3ChartSVG to set available space.
    this.updateSize();

    // Move pie-chart to the center of the svg.
    this.setMargins({ top: this.height / 2, left: this.width / 2 });

    // Draw the SVG.
    this.drawSVG();
    ...

The generated SVG looks like that:

<svg viewBox="0 0 439 397" preserveAspectRatio="xMinYMin" class="svg">
  <g transform="translate(80, 60)" class="chart">...</g>
</svg>

The SVG is now available with this.svg. The chart zone inside is available with this.chart.
The chart is the SVG minus the margins. It's the zone to render our chart in.

Then, I can render a pie-chart (or other kind of charts) on data in the chart group with custom code:

    ...
    // Draw a custom pie chart.
    const outerRadius = Math.min(this.width, this.height) / 2;
    const arc = d3Arc().innerRadius(outerRadius / 2).outerRadius(outerRadius)
    const pie = this.chart.selectAll()
      .data(this.pie_(data))
      .enter()
      .append("g")
      .attr('class', 'arc');
    // Draw pie slices
    pie.append('path')
      .attr('d', arc)
      .attr('fill', (d, i) => HEX_COLORS[i])
      .attr('stroke', 'white')
      .attr('stroke-width', '2px');
    // Draw text in slices
    pie.append("text")
      .attr("transform", d => `translate(${(arc.centroid(d)[0] - 12)} ${arc.centroid(d)[1]})`)
      .attr("dy", ".35em")
      .text(d => d.data.id);
  }

Then if you do:

const chart = new PieChart();
chart.draw();

It renders:

And then to refresh, you can add this function:

  Refresh() {
    this.removeSVG();
    this.updateSize();
    this.draw();
  }

Full JS here.

Draw a Cartesian chart

Directly taken from the d3-helper pie-chart example.

For Cartesian charts, it's more or less the same principle. I use the CartesianChart class that extends from BaseD3ChartSVG class to render the axes in a SVG. Then, I write custom code to draw my data in a chart.

The CartesianChart is based on the type of the data (number, text or date), and on a configuration object. The minimal configuration is the keys of the data to use to set the axes (expected data are Objects in an Array):

    const config = {
      xAxis: {
        axisColumn: 'distance',
      },
     yAxis: {
        axisColumn: 'elevation',
      },
    };

To draw the SVG with the axes, you can write:

    // Set the config for CartesianChart.
    this.setConfig(config);
    // Use BaseD3ChartSVG to draw the SVG.
    this.removeUpdateDrawSVG();
    // Already optional, use CartesianChart to get label for axis from the data (as we have no label in the config).
    this.useDataLabelAsDefaultForAxis('xAxis');
    this.useDataLabelAsDefaultForAxis('yAxis');
    // Set and draw axis using CartesianChart.
    this.setXAxis(data);
    this.setYAxis(data);

That's it. Then we can draw a line chart for instance:

    // Draw a custom line chart.
    const lineFunction = d3Line()
      .curve(d3CurveMonotoneX)
      .x((d, i) => this.xScale(this.xData[i]))
      .y(d => this.yScale(d));

    this.chart
      .append('path')
      .attr('class', 'line')
      .attr('d', lineFunction(this.yData))
      .attr('stroke', `rgb(${this.color.join(',')})`) // use the default color.
      .attr('stroke-width', '1')
      .attr('fill', 'none');

It renders:

Full JS here

Supplementary notes

In the Cartesian chart of d3-helper, data can't cross the axis (but negative values are possible). But if it's needed it's possible to override the drawXAxis method to change this behavior.
It is possible to have two y axes: one y axis, and one opposite y axis (look at the chart below). But it can have only one x axis.
Take a look at the Cartesian configuration and the project examples for all possibilities.

Another Cartesian chart result with more configuration full JS here:

It renders:

More - Implementation in a project

If you have only one simple chart to draw, you can use the same implementation as in the previous examples.

In one of our projects, we had to display multiple Cartesian charts (bars, scatter plot and lines). We made a component (We use Angular in this project, but any "view-level class" can do the same) that extends an adapter, that extends this CartesianChart. This component can set an HTML class via the configuration (to set the correct chart using a unique DOM path). That allows us to have some of these components on one page, and so multiple charts on the same page.

To have cleaner code, we separate line, point, vertical bars and horizontal bars charts in four classes. These classes implement an interface (we use Typescript) ChartDrawer. Each ChartDrawer has a ctx object that is a CartesianChart class, and a draw method. Then we have a configuration to say which data must be drawn by which ChartDrawer. That allows us to have lines, points and bars on the same chart, but with clean code. Each class is responsible for its own rendering and interaction possibilities.

The final implementation looks like this:

The code is quite well organized, flexible and testable.

Notes

It's a "half-public" library, made within a private project. We sadly don't have time to look at new issues or PR, except if we experience them directly. But don't hesitate to fork or take a look at examples to implement your charts.
It's only tested on modern browsers with small datasets.