I was surprised to see that the problem of indent-some-code-of-any-language has such a limited selection of solutions. Prettier was the only project I found taking it on. I'm not super happy about having to bring nodejs into the mix, but whatever works, works, I guess.

Hey @U0GA10KA8 , did you see this?

Yes, I like it

@U0GA10KA8 do I recall correctly you are looking at implementing a Prettier Plugin for Clojure? This one is really simple and stupid, and not really meant to be ”THE prettier-plugin-clojure”. It was just something I need for a project. So many things I don't bother with in this one. 😃

Yeah I see, you've done your MVP faster than me 😂

Please feel free to grab whatever you find useful from this one.

I was about to start from no-op implementation and provide a mechanism for adding more and more nuances (that leverage Prettier specifics) on top of it. Seems like instead of doing no-op, it's possible to fallback to cljfmt, which makes it usable from day 1.

Depends on what your goals are, of course, and what you want to learn. I do think that it is better to base a ”real” plugin on zprint rather than cljfmt (unless you're rolling your own formatter). zprint has a lot of knobs and settings. So you could take this MVP approach using zprint defaults and then step-by-step map Prettier options to zprint settings. And then implement zprint-special options and also support providing those via EDN.

I guess a similar approach using cljfmt would also be of value to certain projects. cljfmt is probably the most common formatter after all.

If you're going for speed, neither of cljfmt och zprint is the way to go. On large code bases something much faster would save a lot of time and give faster feedback. Parinfer is probably the fastest indenter out there, but it does only indenting, not any other type of formatting.

I'm not sure big codebase is the big concern. In practice, the only file you mostly format (via hotkey) is the current one. And also maybe some git pre-commit hook runs locally only for changed files. On the CI environments, however, formatting check needs to be performed on the whole codebase, but I guess it can be tolerated to be running for up to 30–60 seconds.

I happen to know of a codebase where they wish for something much, much speedier than cljfmt.

It is a daunting task to address that issue though. Maybe you can take that on next. 😃

Well, now you made me wonder what's inside Prettier cache dir 😁

Hmmm, maybe Prettier is smart about its cache and could help because of that... In this codebase I am thinking about they have some own cache solution and it often gets confused when switching between branches and you end up having to cljfmt everything before commit. Which is a horrible Dx. So maybe, maybe, even if the Prettier plugin have just wrapped cljfmt, it could still improve things...

What data format do you use for the analysis? Is it hard to plug in new repos? I have a data dump of analyzing 11k repos with clj-kondo, https://blog.phronemophobic.com/dewey-analysis.html#Results

I'm storing the analysis results in a SQL DB. I've attached a screenshot of the schema. It's a work in progress as my understanding of Clojure improves. Some bits of the schema were added to make certain queries a little more convenient to access and some of the structure is there because I thought I'd eventually be adding more data in those places. It could probably have a more compact representation and be more normalized. It's not hard to plug in new repos, but it does take some time. The results are also not perfect, which leads to some findings being omitted due to unsatisfied normalization constraints. When I looked at the failures, most of them seemed to be related to misconfigured clj-kondo hooks in those libraries, leading to mismatches in the usage results. I'd definitely like to look for more opportunities to use inputs from the community to make improvements. If there's some way to adopt your analysis results (or, conversely, my schema) while still being able to satisfy the core feature set, I'd be up for that. I glanced through the Dewey data some time ago and ultimately decided to do my own ETL, but I will find some time to look at it in more detail.

@UPWHQK562 This is super cool! :)

@borkdude many thanks to you and others in the community creating great tools that make this kind of thing fun to implement 🙂

c/c @U066U8JQJ about pathom

@UPWHQK562 that's amazing. Is it possible to spin a separate SeqFinding locally? For example, I'd like to use it at Nubank and see how libraries are used on multiple nubank projects etc

Also, not sure you considered using clojure-lsp dump for that as well, as it has a better understanding of project source-paths automatically

it would help fixing some limitations like only supporting deps.edn ATM

> Is it possible to spin a separate SeqFinding locally @UKFSJSM38 at the moment it is not, but providing a companion tool for local usage is something I've thought about a little bit. It could potentially be used to optionally inform SeqFind web about ecosystem developments - like a crowdsourcing helper sort of thing. > Also, not sure you considered using clojure-lsp dump I did consider it! I initially had the idea to mirror clojure-lsp's data format as much as possible, but clojure-lsp dump wasn't available when I started this effort. It is very much a direction I would like to explore.

Awesome, LMK if need any help, SeqFind looks really great, congrats!

One of the goals for dewey is to make this sort of analysis available for tool writers. The analysis data does include all the raw info, but in a slightly different format. If we did achieve some consensus on a particular data schema, I would be happy to adopt it. Ideally, it wouldn't be coupled to any particular database, but could provide tools for easy loading.

@UKFSJSM38, I also wasn't aware of clojure-lsp dump. I'll take a look for the next dewey update.

@U07M2C8TT provided some interesting insights into clojure-lsp's approach in this https://clojurians.slack.com/archives/CPABC1H61/p1662144341021069?thread_ts=1662052808.444659&cid=CPABC1H61 a while back. Basically LSP uses its current format because editor integration requires writing new data to be fast so as not to introduce editor lag. In SeqFind's case the needs are somewhat reversed because there are practically no write operations outside of the ETL routines (which can run in the background without degrading user experience) but being able to report on aggregate stats over many projects is a core requirement that clojure-lsp doesn't have.

And this is why clj-kondo's data export is the way it is: just a few buckets with flat unindexed data, because you can never predict in which way people need to use this data :)

Yeah, that's why clojure-lsp dump provides clj-kondo analysis and its dep-graph as it is that is what we use internally for editor features, creating a third API would be too much I guess

@UPWHQK562 You could also consider that people could make an alias in their project :seqfind {...} such that clj -Spath -A:seqfind gives the classpath that should be used for analysis or so. Clerk does something similar

or perhaps clj-kondo should support such an alias

Anyway, great stuff. As you know, keyword and locals analysis is also available, not sure how useful it would be for this project

Very cool @UPWHQK562!

I don't know exactly how locals would fit, but there's probably some way to get value out of it. I can imagine keyword reporting when considered on a temporal plane ie. "when did a keyword first start getting used?", but that would require doing commit history analysis and would increase complexity quite a bit. Keyword reporting could be particularly useful for libraries that fully qualified keywords in namespaces they control (reverse domain name notation or something). For example, Fulcro RAD uses keywords such as :com.fulcrologic.rad.report/before-load for configuring reports. I can imagine it would be helpful to be able to find usages thereof when figuring out how to use that. I guess just including a robust search might satisfy such use cases though.

I'm extremely interested in a database of specs (and their keywords)

Another reason to include keywords is that you might be using a web framework like luminus and come across some keyword config and would like some extra docs.

Wow what an idea! Loved it! I love ideas that generate/extract very much needed auxiliaries (docs, specs, examples, tests...) "incidentally" from the main effort (i.e no extra effort for the extra mile) 👏 👏 👏

This is very cool! One note/thought: The top listed library is clojure itself, and under "namespaces" column says 1140. Is that "number of namespaces within clojure library" or "number of other libraries that use depend on the namespace clojure"?

@UEENNMX0T good catch! Definitely a bug because querying the db directly doesn't produce the same result. I will have that patched up for the next iteration. Thanks for pointing it out 🙏