Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2023-07-27

Channels

#cljs-dev
<
2023-07-27
>
vemv18:07:01

It would seem very much handy for tool makers if the cljs analysis (i.e. the object that has a :cljs.analyzer/namespaces key, among others included a :form when descring a var e.g. I'm asking for a :form to be associated here: 

{:meta {,,,},
 :form (def foo 42) ;; <--------------
 :name shadow.remote.runtime.api/foo,
 :file "shadow/remote/runtime/api.cljc",
 :end-column 30,
 :column 8,
 :line 13}
is this a FAQ / something you'd consider?

vemv20:07:08

thanks! Good leads, I'l try making use of those

vemv20:07:02

An edge case being, forms defined at the repl / interactively, those cannot be fetched from source+line+col Given that those would be like < 1% off all cases, it would not be memory-expensive to include them

thheller20:07:03

well there is also the extra concern for cache related things

thheller20:07:34

currently this data is written to disk as transit per namespaces (for shadow-cljs at least)

thheller20:07:57

which would also cost performance I guess

thheller20:07:05

what would you do with the form in the first place though? should probably first provide a proper use case before anything is decided 😛

vemv20:07:27

Thanks. The use case would be "arbitrary tooling stuff". The usual suspects: offering better completions, refactorings, info, and such.

thheller19:07:32

otherwise it might increase memory use? and may contain not easily serialized stuff, e.g. regexes are not part of EDN or transit by default

vemv20:07:02

An edge case being, forms defined at the repl / interactively, those cannot be fetched from source+line+col Given that those would be like < 1% off all cases, it would not be memory-expensive to include them