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?
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
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
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
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
libdirectory; usually these are associated with compilation artifacts rather than source. Something like
coremay be more suitable.
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
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
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