This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (4)
- # architecture (4)
- # aws (1)
- # beginners (64)
- # cider (26)
- # clara (9)
- # cljs-dev (45)
- # cljsrn (1)
- # clojars (8)
- # clojure (31)
- # clojure-finland (3)
- # clojure-italy (3)
- # clojure-nl (3)
- # clojure-poland (9)
- # clojure-spec (1)
- # clojure-uk (81)
- # clojurescript (35)
- # core-async (1)
- # cursive (33)
- # datomic (29)
- # editors (4)
- # emacs (2)
- # fulcro (22)
- # jobs (4)
- # leiningen (2)
- # off-topic (20)
- # onyx (1)
- # portkey (17)
- # proton (2)
- # re-frame (20)
- # reagent (36)
- # remote-jobs (1)
- # ring-swagger (1)
- # rum (2)
- # shadow-cljs (179)
- # slack-help (1)
- # spacemacs (1)
- # test-check (20)
@kingmob I’m not sure why
:welcome wouldn’t be shown, since Cursive doesn’t mess with that part at all - perhaps it’s a REPLy thing? I’m not sure.
There isn’t an ns cleanup yet, although it’s one of the most regularly requested things so it’s near the top of my list. I’m slowly working through the list of cases required to make it work reliably in cljc, which is the main blocker.
Well, if you can make ns clean-up work in cljs, you’ll be ahead of CIDER. It routinely messed up converting :use to :require.
Nice to know - both clj and cljs are relatively easy, as is cljc if there are no reader conditionals.
Modern cljs actually requires far fewer of them, but the
ns form is still one of the main places they’re used.
Only other caveat is, be careful removing unused namespaces from
ns. Especially with foreign-libs, there can be included namespaces that have no obvious symbols referred to, so it’s easy to assume they’re unused. But they may supply js/ globals or even necessary polyfills.
BTW, would you suggest cljc as a way to mix cljs fns with their macros… or not?
It depends. If you are writing cljs, and the only reason you need the clj is for a macro, then it can be ok; however, it gets really confusing to have them in the same file. I generally recommend keeping them separate. I beat my head against a wall for almost an entire day doing something that I saw in a file that I thought was written by David Nolen that combined them into a single file. Turns out it was a contrib that had a deeply confusing problem that neither the author nor David caught that combined them in a CLJC file in a way that was impossible to ever work. The reason it didn’t get caught is that the change was for an optimization…so everything looked to work when tested…it was just slower than intended.
Yeah, it can be hard to tell if a namespace is really required. In clj as well, an app can rely on load order (not a good idea, but apps can and do do it)
I’m probably not a great person to ask about your cljc question, since my use of cljs is very simple (I’ve never actually written a cljs macro)
@cfleming Does “Find Usages” ignore profile-specific source paths? E.g., I have a fn that’s only used under
env/dev/cljs/, which is only added in the :dev profile. If I run “Find Usages”, it won’t be found, but if I just do plain “Find”, it has no issues locating it.
hey has anybody upgraded intellij on mac? I’m scared to do it because when i upgraded from CE to UE, I lost all of my settings. If i just drag the icon into applications, is that going to work?
Yeah, I just upgraded to the latest IntelliJ that way, no problems. It asked if I wanted to import my old settings and I said Yes, and boom, ready to go
If you want a backup copy of everything you could re-name the old app and look for it’s data folder in ~/Library/Application Support
Looks like the App Support folders are all versioned though, so you should be safe.
Once a source path is marked as such, IntelliJ makes no distinction between them. The profile stuff only affects the actual import itself, i.e. which paths are marked as sources.
Wait, I think I figured it out. The same fn is coming from a different ns in
dev. The real thing is only in
prod. When I added the
prod dir, “Find Usages” found it
Do we need to be careful about specifying resources and exclusing output dirs?
Excluding output dirs is generally a good idea, yes, particularly with CLJS, since they get filled with gnarly JS code which IntelliJ will otherwise try to index.