This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (18)
- # babashka (52)
- # beginners (47)
- # calva (45)
- # clj-kondo (31)
- # clojure (18)
- # clojure-brasil (2)
- # clojure-europe (3)
- # clojure-sweden (25)
- # clojurescript (19)
- # cursive (15)
- # datalevin (11)
- # defnpodcast (2)
- # duct (1)
- # editors (1)
- # emacs (6)
- # gratitude (1)
- # introduce-yourself (6)
- # jobs-discuss (11)
- # leiningen (3)
- # lsp (10)
- # luminus (2)
- # off-topic (4)
- # podcasts (2)
- # reitit (2)
- # shadow-cljs (10)
- # sql (9)
- # xtdb (4)
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. 💜 Calva is in much better shape now.
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.
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.
I think this is the rule that's in play here and the reasoning makes a ton of sense to me https://github.com/import-js/eslint-plugin-import/blob/02ccbc1a30098822b7a6e7d84d8594b387495361/docs/rules/no-named-as-default-member.md
which is really saying that using export default alongside named exports results in some confusing behavior.
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
in the rule @U0ETXRFEW commented on there is a named export https://github.com/BetterThanTomorrow/calva/blob/published/src/evaluate.ts#L590 alongside a default export https://github.com/BetterThanTomorrow/calva/blob/published/src/evaluate.ts#L628 -- and the code that imported it was importing it like it was a default export https://github.com/BetterThanTomorrow/calva/commit/fd89b14c4c4b6e1b4928796ad7f9b5c4b7e4ed86#diff-93f9f09a29cd12cc70ff95aca80720b00ef8acd54370b9e0e18c8752b45a8196R19 and then calling the named export function on from the defaults https://github.com/BetterThanTomorrow/calva/commit/fd89b14c4c4b6e1b4928796ad7f9b5c4b7e4ed86#diff-93f9f09a29cd12cc70ff95aca80720b00ef8acd54370b9e0e18c8752b45a8196L124
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
that PR even shows an example of that working https://github.com/BetterThanTomorrow/calva/commit/fd89b14c4c4b6e1b4928796ad7f9b5c4b7e4ed86#diff-93f9f09a29cd12cc70ff95aca80720b00ef8acd54370b9e0e18c8752b45a8196L18
@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.
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
bar do you get, the one from the default export or the named export?
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 😂
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.
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.
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.
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: https://github.com/BetterThanTomorrow/calva/issues/76
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
getPrompt() that don’t take any params and rely on a globally set repl env.
I’m currently working on getting some https://github.com/BetterThanTomorrow/calva/pull/1518 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?
So what are you expecting to see in the above code? What are you expecting to see underlined in gold?
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
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.