You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Get rid of externs requirement for pure CLJS builds #498
There is a very long open issue that datascript requires externs even for pure CLJS compilation. This should never be neccessary for builds where all code is part of the build. Given that shadow-cljs doesn't add externs by default this creates problems. It even has become part of the entry README.md since I assume this is a common issue.
I had a suspicion what the problem is and used AI to confirm. It did, but I do not know enough about this codebase to know if its suggested fixes would actually work. So, here goes the problem.
The code is running into the Inconsistent Property Names problem. Meaning that some places use foo.e and other use foo["e"]. Or more likely the CLJS variants of (.-e foo) and (aget e "foo") (or unchecked-get or any other string based property access). I can see several uses of aget in the codebase, most notably the getter-fn in datascript.query. Given that the set of property names is known it can just use direct getters and not mix in string lookups.
There is also another situation where code contains forced goog/exportSymbol code that is also never necessary for pure CLJS builds and should only be present for the JS targetted builds, not part of the raw sources the CLJS builds will use. But that is a different unrelated issue. Just leads to a lingering datascript global that is also causing problems in ESM builds.
I'd advise moving all the JS build related bits into their own files and doing that build with externs. That would leave the JS build functioning as is, while likely fixing all the CLJS related build issues.
I have no interest in pursuing this myself any further, but given that AI can most definitely fix this, I thought I would bring it up just in case there is any interest in "fixing" the current situation.
Yeah I know what the problem is. Basically datoms are represented as {e, a, v} but during queries these are abstracted away as column names. I’ll see if constructing/accessing datoms dynamically has any performance penalty.
Activity
tonsky commentedon Sep 2, 2026
Yeah I know what the problem is. Basically datoms are represented as {e, a, v} but during queries these are abstracted away as column names. I’ll see if constructing/accessing datoms dynamically has any performance penalty.