[Discussion] Refactor jerry-client-ws.html/py into reusable library

[martijnthe]

Right now there are 2 debugger client implementations: 1) a CLI client written in python 2) a browser based client written in HTML/JS.

Both re-implement similar thing. Both are written in ways that make it hard to reuse pieces of the code in other contexts, mainly because they are written as large, monolithic blobs of code.

During the last JerryScript Workshop in the Fall of 2017, we talked about the desire to be able to leverage existing JS debugger infastructure, to avoid re-inventing the wheel and re-creating the functionality that already exists in existing debugger clients such as IDEs.

I think the first stepping stone towards that goal is to rewrite/refactor the existing debugger client code into a re-usable library that other tools can be built on top of (a CLI interface being one of them).

In terms of language of choice, we would like write this library in TypeScript because of the many advantages a typed language gives and because it transpiles into JS and can therefore easily be run inside Node.js (for CLI tooling), inside a browser or even inside JerryScript itself ;)

When written in TS/JS, this libary can be published to npm, to make it easy to consume the library as well.

I imagine to build this library alongside the existing clients and as soon as the library is "at par" with the existing clients, rework the existing clients to make use of the library. At that point, the jerry-client-ws.py would be replaced with a tiny Node.js program that wraps the libary and implements the CLI.

Questions

What does the core team think of this idea?

Are there any major changes / extensions to the protocol planned?

Where would the sources of the library live / what is the development repo?

In my opinion, it would be easiest if the sources for this library live in the main jerryscript project. That way, any changes that affect the client and server sides can be reviewed in a single PR. From a CI/testing point of view, this is also the simplest set up.

That said, how to manage PRs / reviews and make sure we can move fast? I am not sure if the JerryScript core team is comfortable reviewing TypeScript code. Assuming that the people writing the code will mostly be me / my coworkers and not people from the JerryScript core team: we don't want to loose development velocity because the code that gets written doesn't get reviewed and approved in a timely manner.

An alternative approach could be to develop initially in a different repo (under our control) and contribute it back "wholesale" at once (and potentially deprecate that different repo after that point).

[martijnthe]

cc @grgustaf @akosthekiss @DanielBallaSZTE @polaroi8d @zherczeg @hbehrens

[zherczeg]

I don't mind having a single code base as long as it is easy to use. Currently you just run the python debugger like an application (it starts with #/bin/python), and works. I wouldn't want to add a building step or other complicated mechanisms. Designing a good API for reusable code is also a challenging task. I don't know how other JS debuggers work.

Personal note: I am not familiar with TypeScript.

[DanielBallaSZTE]

@knightburton

[knightburton]

In my opinion, a well defined API would be great. In the iotjscode, the debugger client implementation is separated into four module, which are carry out the communication and parsing. The iotjscode is covers many areas that the client implementation should know. I think the current 1.0 debugger is enough to create a reusable API.

I am familiar with TypeScript a bit, I would say that I am a beginner yet, however I support this line because this would be great for the iotjscode and Visual Studio Code debugger extension, too.

[LaszloLango]

Note: https://github.com/Samsung/iotjscode project could be related to this issue.

[martijnthe]

Currently you just run the python debugger like an application (it starts with #/bin/python), and works. I wouldn't want to add a building step or other complicated mechanisms.

I guess the current python script has no dependencies other than Python itself. That's a bit hard to beat in terms of set up convenience.

I'd opt to add a package.json to the root of the jerryscript repo so that one can do npm install or yarn install to get any any npm dependencies downloaded easily. After that I think running the debugger CLI should be as simple as npm run jerry-debugger / yarn jerry-debugger or something along those lines.

@zherczeg: how does that sound?

Designing a good API for reusable code is also a challenging task.

@zherczeg: Agreed, but I think that the existing python+web clients + the iotjscode client + our own client should give enough "input" to be able to design a reasonably good API, don't you think?

I am familiar with TypeScript a bit, I would say that I am a beginner yet, however I support this line because this would be great for the iotjscode and Visual Studio Code debugger extension, too.

@knightburton Great to hear that. Are there more people in the core team that know TS to one degree or another and could help review?

I'd still like someone to chime in on question 3 "Where would the sources of the library live / what is the development repo?". @akosthekiss perhaps?

[martijnthe]

FYI, we're starting the work here -- currently in a clone of the repo (under my personal Github for now): https://github.com/jerryscript-project/jerryscript/pull/2205

[LaszloLango]

This is moved into a new repository: https://github.com/jerryscript-project/jerryscript-debugger-ts