ah, cool - let me give that a try

FAIL  dist-test/todomvc.app_spec.js
  ● Test suite failed to run

    Your test suite must contain at least one test.

      at onResult (../node_modules/@jest/core/build/TestScheduler.js:175:18)
          at Array.map (<anonymous>)

changed jest.config.js

testMatch: [
    "**/*_spec.js"
  ],

and using this build config

{:target :npm-module
  :ns-regexp "-spec$"
  :output-dir "dist-test"}

hehe I was just typing that....

out of curiosity, have you tried jest with shadow before?

no

we're experimenting with it at Pitch, where we want to improve our frontend testing story

several people have asked in the past but I never got around to it. thanks for the repo, made it really easy to try 🙂

we got it to work with the :browser-test target but that felt hacky and I thought there must be a better way

:npm-module seems to work as far as I can tell

even (jest) watch works

FAIL  dist-test/todomvc.app_spec.js
  ✕ arithmetic (5 ms)

  ● arithmetic

    expect(received).toBe(expected) //  equality

    Expected: 5
    Received: 4

      at Object.<anonymous> (todomvc/app_spec.cljs:9:27)

even release seems to work so seems all good

awesome!

it source maps. that is gonna help a lot. seems good.

i'm going to hack on it some more

I don't like the test syntax all that much but a few helper functions/macros might make that bearable

going to try to implement todomvc based on tdd using Jest + React Testing Library

yeah, we already have a wip wrapper ns for jest assertions

there could totally be a :target :jest if needed but AFAICT :npm-module seems to do everything you'd need

would you be open to a PR to the user guide once the dust settles?

sure

it's quite fast on incremental builds in this minimal repo

PASS  dist-test/todomvc.app_spec.js
  ✓ arithmetic (2 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.578 s, estimated 1 s
Ran all test suites.

yeah first run seems slow but after that it appears to use some cache and only process actually changed files

still sometimes slow for me. dunno why

I'm surprised all of this works with node's require() etc - the combination of node's require() and goog.provide etc is not something I can claim to understand

well :npm-module basically creates some glue code to pretend we still have everything in the same global scope but actually don't

quite hacky but make CLJS/Closure output look like commonjs for the tools that need that

should have named it :target :commonjs but oh well naming is hard 😛

$ shadow-cljs clj-repl
shadow-cljs - config: /Users/user/pitch/shadow-jest/shadow-cljs.edn
shadow-cljs - connected to server
shadow-cljs - REPL - see (help)
To quit, type: :repl/quit
shadow.user=>

whoa I had no idea!

I'll use that a lot

how is this so fast?

shadow-cljs - connected to server

it's like 10x faster than lein repl :client ....

it is connected to the running watch you have I guess

yeah it is, but using lein as a mere nrepl client is already slow as molasses

well yeah its not starting a new JVM. just the node script opening a tcp socket

so it's not using nREPL then?

no, just the socket REPL

ah, so much better

(sometimes I wonder how much damage lein and nREPL, with their slowness and complexity, have done to Clojure)

I like lein. nREPL not so much 😛

omg I just added a watch for the app build via the socket repl

(shadow.cljs.devtools.api/watch :app)
[:app] Configuring build.
[:app] Compiling ...

shadow is so nicely decomplected!

(shadow/watch :app) from shadow.user 🙂

I pretty much only run shadow-cljs server these days and do the rest over the UI

guess I'm weird that way 😛

@pesterhazy The slowness of lein just comes from loading many dependencies every time, I think. A comparable tools.build program with clj can be equally slow, if you're not mindful about which deps you are bringing in in your namespace form.

I think most people complaining about slow startup of lein just have a user.clj sitting on the classpath that contributes most of the slowness. Otherwise IMHO its fine.

Well, I think an argument can be made that lein tries to do too may things, so it ends up not doing any of these well. But of course I shouldn't have said "damage". We owe a lot to lein's original authors, and I'm in no position to complain, having written little in the way of OSS

heresy