Stream: jsCoq

Topic: Component organization


view this post on Zulip Emilio Jesús Gallego Arias (Aug 20 2022 at 16:43):

Hi @Shachar Itzhaky , it seems to me that indeed it is time to organize the repos a bit better in term of filesystem layout and structure, we are still bound to the initial setup which is showing its age.

It seems to me that we could start by splitting the backend from the frontend (we could even make them different packages indeed, not needed now yet). There are some components that indeed sit a bit in the middle of the two, but for now we could have something like:

backend/lib
backend/intf
backend/wa
backend/jsoo

and indeed maybe switch the backend to full typescript, so the intf file is a pure typescript one and actually abstracts away the communication with the worker. So we can expose there as in LSP notifications and requests, using the regular API vsCode uses (I think Promises)

Then, we could have a frontend directory that depends on the backend (bundled) interface. Maybe we should have

frontend/lib
frontend/node
frontend/cm

?

Another interesting stuff is how to manage our vendored dependencies. Maybe using some patch queue system with the submodules pointing out to public branches would be convenient? I'm not sure.

How does the above look to you?

view this post on Zulip Emilio Jesús Gallego Arias (Aug 20 2022 at 16:44):

I guess package-manager should also be its own directory.

view this post on Zulip Shachar Itzhaky (Aug 20 2022 at 16:47):

ok yes although I'm not so sure about the naming and these particular subcomponents. Would intf be just the interface? Then I think a file backend/index.d.ts is conventional. I do not like the concept of lib directory; usually these are associated with compilation artifacts rather than source. Something like engine or core may be more suitable. The package manager should be part of the core I believe? Because nothing can work without packages.

view this post on Zulip Shachar Itzhaky (Aug 20 2022 at 16:49):

In wacoq-bin, the entire backend is under backend/ (https://github.com/jscoq/wacoq-bin/tree/v8.16/src/backend).

view this post on Zulip Shachar Itzhaky (Aug 20 2022 at 16:50):

This includes packages.ts which indeed is a bit of duplicated code w.r.t. what we have in jsCoq because jsCoq's one was hard to separate from the UI.

view this post on Zulip Shachar Itzhaky (Aug 21 2022 at 12:50):

Oh I forgot to ask you: can we / do we want to get a proper domain name? Have one allocated by Inria maybe?

view this post on Zulip Emilio Jesús Gallego Arias (Aug 22 2022 at 14:28):

Shachar Itzhaky said:

Would intf be just the interface? Then I think a file backend/index.d.ts is conventional.

Isn't that a compiled artifact from the rest of .ts files? But indeed we can have an index.ts and the rest of files as we see fit.

I do not like the concept of lib directory; usually these are associated with compilation artifacts rather than source. Something like engine or core may be more suitable.

How about common ? lib is used in OCaml land for common stuff but indeed not a good name in the TS world. The idea of that dir is to put the files that are not backend-specific there.

The package manager should be part of the core I believe? Because nothing can work without packages.

Indeed it seems that we should maybe try to split the package manager backend from the frontend then?

view this post on Zulip Emilio Jesús Gallego Arias (Aug 22 2022 at 14:30):

Yup, I got the backend name from looking at wacoq hehe

view this post on Zulip Shachar Itzhaky (Aug 22 2022 at 15:22):

Yeah I am not too strict about the directory naming. IMO common is not very illustrative for newcomers because it does not hint to what modules it is common. E.g. in a setting where you have components client, server, and common, it is quite clear what being "common" means. In our situation not so much which is why I would prefer core. Or, just put all the files in backend with some more specific ones in wa and jsoo.

view this post on Zulip Shachar Itzhaky (Aug 22 2022 at 15:23):

Also for the interface file my understanding was that it should provide typings for OCaml modules that are compiled to JS. In such case IIRC there is no automatic way to do it so we would have to write it manually. No?

view this post on Zulip Emilio Jesús Gallego Arias (Aug 22 2022 at 16:10):

For now we gotta write it manually, not sure of the status of the tools that can do that. They should not be hard to write actually.

view this post on Zulip Emilio Jesús Gallego Arias (Aug 22 2022 at 16:11):

I had an skeleton of a tool somewhere in my github, you just need to map OCaml's type AST to typescript's AST

view this post on Zulip Emilio Jesús Gallego Arias (Aug 22 2022 at 16:11):

for most cases of our interest that's not hard


Last updated: Jan 30 2023 at 17:03 UTC