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?
I guess package-manager
should also be its own directory.
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.
In wacoq-bin, the entire backend is under backend/
(https://github.com/jscoq/wacoq-bin/tree/v8.16/src/backend).
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.
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 likeengine
orcore
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?
Yup, I got the backend
name from looking at wacoq hehe
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
.
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?
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.
I had an skeleton of a tool somewhere in my github, you just need to map OCaml's type AST to typescript's AST
for most cases of our interest that's not hard
Last updated: Dec 07 2023 at 14:02 UTC