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 foo.bar, which 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 😂

stop selling me more on ClojureScript 😈

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.

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.

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.

Right. Thanks a lot!

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: 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 openResultsDoc() and 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!

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

https://github.com/BetterThanTomorrow/calva/issues/1546

Thanks