This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-08
Channels
- # announcements (8)
- # aws (2)
- # babashka (11)
- # babashka-sci-dev (39)
- # beginners (62)
- # calva (5)
- # cider (1)
- # clj-kondo (50)
- # cljdoc (2)
- # cljs-dev (6)
- # clojure (52)
- # clojure-austin (22)
- # clojure-czech (13)
- # clojure-europe (88)
- # clojure-nl (1)
- # clojure-norway (5)
- # clojure-uk (6)
- # clojuredesign-podcast (13)
- # clojurescript (45)
- # community-development (3)
- # core-typed (31)
- # cursive (12)
- # datahike (2)
- # datalevin (7)
- # datomic (5)
- # events (1)
- # exercism (11)
- # fulcro (27)
- # gratitude (1)
- # holy-lambda (3)
- # hoplon (2)
- # introduce-yourself (2)
- # jobs (1)
- # lambdaisland (3)
- # lsp (110)
- # malli (2)
- # meander (4)
- # music (2)
- # off-topic (50)
- # overtone (1)
- # pathom (13)
- # polylith (26)
- # re-frame (4)
- # releases (2)
- # rewrite-clj (3)
- # ring (12)
- # shadow-cljs (20)
- # specter (4)
- # tools-deps (8)
- # xtdb (40)
Afternoon. Has anyone tried adding new dependencies to nbb and noticed different behavior between dev and release compiled versions? Adding datascript and seeing d/q
fail for some unexpected cases
Nothing fails during compilation. When I run this test ns, https://github.com/tonsky/datascript/blob/master/test/datascript/test/query.cljc, half of the tests fail in advanced mode but they pass fine in dev mode
That's not what I meant. I mean if you notice a difference between dev and prod and then it might be an error as the result of advanced compilation
if you compile with --debug
you might be able to see what goes wrong in the case (if it is that)
Ah gotcha. The buggy release build definitely seems caused by advanced compilation. Will try --debug
If you're curious, here's the branch - https://github.com/babashka/nbb/compare/main...logseq-cldwalker:add-datascript?expand=1 . Steps to repro test failure:
$ NBB_FEATURES=datascript,datascript-transit bb compile
# Passes
$ node lib/nbb_main.js test-scripts/datascript-test/query.cljc
$ NBB_FEATURES=datascript,datascript-transit bb release
# Tests fail
$ node lib/nbb_main.js test-scripts/datascript-test/query.cljc
With NBB_FEATURES=datascript,datascript-transit bb release --debug --verbose
didn't see any obvious failures or culprits. My next troubleshooting steps are:
• see if it's an externs issue. Dunno how good shadow's :auto inference is
• Look into the ns behind d/q
, https://github.com/tonsky/datascript/blob/master/src/datascript/query.cljc, and see if any of the underlying namespaces aren't behaving as expected by running tests for the underlying namespaces
I'm open to troubleshooting other ways too
Don't see any other npm/js lib for datascript. It's only other external dep is https://github.com/tonsky/persistent-sorted-set/blob/master/src-clojure/me/tonsky/persistent_sorted_set.cljs
It's been awhile but used to use it a fair amount on browser targets. Don't know if I've used it against nodejs
Failed assertions when I run node lib/nbb_main.js test-scripts/datascript-test/query.cljc
e .g.
FAIL in (test-q-in) (/Users/me/code/work/nbb/test-scripts/datascript-test/query.cljc:99)
expected: (= (d/q query db :name "Ivan") #{[1] [3]})
actual: (not (= #{} #{[1] [3]}))
No explicit exceptions. Would be much more helpful if I had thatyep. works fine. Interestingly enough, this issue so far seems specific to d/q
behavior. These two other test namespaces pass fine in dev and advanced mode - https://github.com/tonsky/datascript/blob/master/test/datascript/test/query_rules.cljc and https://github.com/tonsky/datascript/blob/master/test/datascript/test/pull_api.cljc
Looks like this is a known issue - https://github.com/tonsky/datascript/wiki/Tips-&-tricks . I'm able to manually modify the advanced compile js per one of the linked issues. I should eventually be able to get this right with a shadow compiler option 🙏
Thanks for chatting with me. Sometimes a quick chat helps unblock us. This is all the more motivating to get this working with nbb. I don't want logseq users and most cljs users to have to mess with compiler options for esm to be productive with datascript and cljs. 😄
For integration tests, I see the ci:test
task runs off of one release build. Should I add another release build with features enabled or just reuse the existing one to also test datascript?
Similar to bb, it doesn't run tests for features in CI because it would take way too long
That works too. I didn't know if you wanted to test that features worked in some way but happy to run them in my fork
Meaning no whitespace changes in PRs or something else? The recent clojure.test -> cljs.test was helpful. The only manual changes for datascript tests I have to do now are change ExceptionInfo to Error
but to kick off the tests for your fork which you are going to distribute I assume, you run the tests