Fork me on GitHub

Calva 2.0.242 is out. It is ”just” a maintenance release which upgrades TypeScript and applies basic linting rules to the project (plus updated almost all TypeScript files to comply). I released it separately so that any breakage we could introduce with some feature release won't mean we have to revert these changes. Huge thanks to @corasaurus-hex for taking on these important tasks. 💜 gratitude Calva is in much better shape now.

💜 2
gratitude 1
Lukas Domagala12:02:36

I’m rebasing my PR’s onto the new style and I’d like to start a small discussion: Do we really want to ban import * as AirbnbStyleGuide from './AirbnbStyleGuide';? This makes sense for the OO typescript approach, but most of our modules are just a bunch of functions, and importing those feels wrong to my clojure brain. Calling util.testDataDirfeels like using a ns, pulling testDataDir in feels like referring it in.


We're not banning this style yet, are we? I commented on the PR in much the same vein, that I like that style.

Lukas Domagala15:02:39

Ah ok. I did see the comment but also saw that a lot of imports got changed. But that’s probably just switching “” to ‘’. Good to hear we can keep the old style.

Cora (she/her)19:02:32

which is really saying that using export default alongside named exports results in some confusing behavior.

Cora (she/her)19:02:39

if it's disallowing what you put above then I'd love to see what rule it's violating and reason through it with you! maybe the wrong rule is enabled

Cora (she/her)19:02:03

import * as foo from 'bar' should still work, but foo will contain the named exports and not the default exports. it's extra confusing when there are overlapping names between them, too. I usually avoid default exports because of this confusion

Lukas Domagala00:02:00

@corasaurus-hex Thank you for the explanation! I ran into conflicts and then read the Airbnb guide you linked and assumed (I know, don’t do that 😞) that we also follow that rule in it. I like the idea of avoiding default exports and keeping exporting mostly functions.

💜 1
Cora (she/her)00:02:24

clearing up ambiguity is what sold it to me. like what if the default export and a named export have the same name bar? when you import foo from 'foo' the call, which bar do you get, the one from the default export or the named export?

Cora (she/her)00:02:44

I even like exporting all the exports at the end of the file so they're all in one place and it's unambiguous what's being exported. I've definitely lost that fight in every project I've been on though 😂

Lukas Domagala00:02:42

stop selling me more on ClojureScript 😈

😅 1
Cora (she/her)00:02:10

don't get me wrong, I love typescript! it's a great way to tame javascript, and the types really help with interacting with all the browser APIs in an unambiguous way.

Lukas Domagala00:02:08

Yeah I also like it better than pure js, but I’m also very happy any time I don’t have to touch it + the whole module mess


I think exporting everything at the end creates a level of indirection that doesn't give me much.

Oitihjya Sen13:02:24

Hi. I wanted to know how we can close/restart a REPL session on VS Code (using Calva) without having to close the window ?


Hello! If you have started the REPL using Calva you can restart it by jacking in again, and close it by pressing ctrl+c in the terminal where the REPL is started.

Oitihjya Sen14:02:01

Right. Thanks a lot!

🙏 1

Is it possible to have two independent REPL connections to the same project in different VSCode windows? I tried that and it kinda worked but then the calva.output file got confused.


My use case is a local development REPL and also a remote production REPL. All based on the same checkout.


An obvious workaround is to have two different “checkouts” but it's not ideal as they would need to be synced.


We should support that better. Another workaround is maybe to have a folder somewhere else in the file system, place a deps.edn there using local/root to bring in the main project.


I wonder, is it because of file system issues?


Conjure uses the concept of named sessions, perhaps any new nrepl session would get its own subfolder? Obviously you'd need some UI and indication of which session you're currently in, but that can wait if you can just have two VSCode sessions side by side.


Calva needs tight control over the output window file. So when another Calva is writing to it it probably gets weird.


We want to support multiple sessions. Tracked here:

Lukas Domagala11:02:04

I like the idea of multiple output files, since using the same one with all the async calls that are happening, is bound to be unreadable. The problem is that calva is pretty hardcoded for one output window and one repl session (with clj <-> cljs switching inserted at strategic places). I don’t think it’s impossible, but a lot of calls to functions like openResultsDoc() and getPrompt() that don’t take any params and rely on a globally set repl env. I’m currently working on getting some going for the whole thing. Once those guard rails exist I’d be way more confident refactoring that part of calva to be parameterized. Happy for you to help with the tests though 😇 @U7PBP4UVA


Yes, it is quite horribly entangled in there. We still have that 3 year old issue unsolved for those reasons. Some integration tests will help a lot in moving forward with this!


My Calva seems not to be working as expected, I am only getting the blue highlights. I am missing the gold ones. I have uninstalled and then installed but still


Are you referring to linting decorations? This comes from clojure-lsp via clj-kondo. Are you seeing clojure-lsp startup successfully when you open a Clojure project?


If you run the Clojure-lsp Server Info command, do you see the info reported in the Calva says output window?


Yes I am referring to the linting decorations. Yes I do see the calva says output when opening a clojure project


Can you provide a specific scenario (with code) in which this is happening, and note what you don’t see that you expect to see?


There you go


So what are you expecting to see in the above code? What are you expecting to see underlined in gold?


Yes that's correct


Sorry if my question was not clear. I’m asking what you are expecting to see underlined in gold, that you are not seeing.


For example on the when function, I expected to see the conditions in gold. Hope that makes sense


I don’t see anything in the when form that should trigger a linting warning. Are you sure you’re referring to linting and not syntax highlighting? I would expect the function calls like seq and sort-by to be yellow with the theme it seems to you are using.


Please create an issue on the repo if you are experiencing an issue with syntax highlighting.


Sure no problem let me create that issue. Thanks