we’re running into an edge case regarding how the cljs compiler indexes node modules: https://clojure.atlassian.net/browse/CLJS-3293

would a patch which adds support for .cjs as main files in package.json like this be acceptable? https://github.com/nextjournal/clojurescript/commit/f48609b862062caae6d19d5d281c4f7b53a39c25

sure thing

@borkdude there are performance implications for that

Clojure has class but that doesn't make sense for JavaScript

so I just used type

originally this wasn't done for anything related to Clojure reallly

type was missing and needed for fast membership testing

you can't really just invoke -meta on anything, you will fall into a slow path

at least when I looked ago not very optimizable

so code that would be fast will be punished for things that don't match

all that said, the issues could be separated

@dnolen true, checking :meta is an extra step - is type a thing that is used in hot-loops though? Could be. Does CLJS use type internally for protocols/multimethods? It's not a big problem for me. I hit this issue in sci (Clojure interpreter) because I am using :type on its implementation of records (which are just there for compatibility).

there could be a new thing that does what type used to do, and type could do Clojure behavior

would need a lot of lead time on this because it would be seriously breaking behavior now

so ten years of not following Clojure here might be too much water under the bridge

I suspect many people aren't even aware of type + :type metadata on the JVM

yes

and it's not often requested

So the way it works in sci now is that (= (type x) (type y)) returns true if two things are of the same record type, which I think is better than relying on the concrete return value of type. Although it was also requested to get back the namespace and name of the record type. I wonder if that is possible in CLJS at all.

name is already there

needed for printing

and it's fully qualified

it's a manually mangled property but we're not going to change it