Development: better VS Code experience

[ksachdeva]

Hi,

Really interesting & refreshing approach. I am going to give Julia a try because of this project!

However, it took me by surprise to see the usage of javascript instead of typescript by the community (Julia) who is positioning itself (amongst many other things) for type safety, the arrest of errors at compile (instead of run), being a modern safe language etc which are the goals shared by Typescript as well.

Since your project is still (relatively) new, it may benefit to switch to typescript now and reap the productivity benefits from the get-go.

Just a humble suggestion!

Regards Kapil

[fonsp]

Thanks! We have considered typescript, but we find that it is more important to have a buildless frontend.

But we are not missing out on all the benefits! VS Code already runs type inference on our project, and we use JSDoc to define some important types.

[fonsp]

Sorry for closing this issue so quickly, feel free to respond!

Let's talk about the more general subject of how our development experience can be better

[fonsp]

Some notes:

Browser debugging

The project has browser debugging set up, at least for firefox. It works with breakpoints, value inspection, etc. You need to launch Pluto yourself, and then use the VS Code Debugging panel to start browser debugging. When you refresh, the latest frontend code gets loaded.

Auto reload

I added an auto reload feature for frontend code (like most JS dev servers) based on FileWatching, but it was triggered randomly way too often, so I took it out again. After reading Revise's source code, I realise that this might only be a problem on WSL. Feel free to comment!

Revise.jl

Revise.jl does not work for Pluto development right away, because it normally runs on every REPL input line, but Pluto is a single REPL command. However, I did find that Revise has functionality to trigger itself when it detects a file change, I think we could use this for Pluto dev! Still a bit tricky because our Distributed setup is not homogenous, which Revise isn't designed for. But it can probably be done, Revise 2.7.6 adds support for inhomogenous setups, to support using Revise inside Pluto notebooks. (This is different from using Revise for Pluto dev.)

JSDoc

By adding the .tsconfig file, VS Code already runs type inference on our project and gives linter warnings. It essentially treats JS+JSDOC as Typescrip. We use JSDoc to define some important types, but most functions don't have type signatures. We can add more?

ES6 URL imports (@ekzhang)

We load our JS dependencies using ES6 URL imports from CDNs, but VS Code doesn't understand that, and gives warnings for the imports. It also means that our dependencies don't have typings, and we get errors for things like this.setState.

I spent some time trying to fix it, but nothing really worked. I can say more about my earlier attempts, but the most promising was to use a Deno extension, since Deno projects also use web URLs for imports. This fixed the errors for the URL imports, but it still failed to get type info for those imports, so errors like this.setState are still there.

[dralletje]

I totally agree with the typescript part - JSDoc comments are still lacking sometimes, but it is getting better.

I'll have a look at the types stuff, maybe even copying over the typescript definitions for at least Preact (those are by far the most annoying), we'll see what works

[ekzhang]

Hm, I also just got Deno installed and tried it out. This proposed workaround doesn't seem to work for me either.

I understand why you would want a build-less frontend system to simplify development & tooling (I think it makes HTML export really nice!), but VS Code doesn't like it unfortunately. It seems like they don't support frontend projects to use native JS modules. :(

[shashankp]

I'll have a look at the types stuff, maybe even copying over the typescript definitions for at least Preact (those are by far the most annoying), we'll see what works

New folder for type definitions?

[Pocket-titan]

Adding types to allow for inference is nice, but it doesn't add Typescript's type safety on compile time that @ksachdeva is talking about. Perhaps it is worth revisiting the trade-offs between buildless/buildful (maybe on a small scale)? Bc the cost of adoption will keep growing as the project's size increases (maybe it's past being worth it already) What do you think, @fonsp?

[fonsp]

The project stays buildless

[dralletje]

Iiiiii've added typescript definitions for React and immer, I think we can add small ones as we go