shadow-cljs 2021-12-07 | Slack Archive

I get

-> build target: :browser stage: :flush
invalid :module-hash-names value :duude
{:tag :shadow.build.targets.browser/module-hash-names, :module-hash-names :duude}
ExceptionInfo: invalid :module-hash-names value :duude
        shadow.build.targets.browser/hash-optimized-module (browser.clj:411)
        shadow.build.targets.browser/hash-optimized-module (browser.clj:389)
        shadow.build.targets.browser/hash-optimized-modules/fn--39881/fn--39882 (browser.clj:421)

thheller06:12:30

also for the cli arguments themselves order doesn't matter. they are all applied before the build is started.

pez13:12:12

I’m making an internal library project in a monorepo. We’re using deps.edn for dependencies and the library is then a local dependency. When working on it I find it the most convenient to use it from an app, so I can end-to-end test manually as I work. Is there a way I can make shadow-cljs auto-run the tests for the library while working like this? It rebuilds the app as I change stuff in the library implementation, but I can’t figure out how to make the same thing happen with the library tests…

thheller15:12:06

@pez I assume putting a shadow-cljs.edn into the lib and running the tests there is not the answer you are looking for?

pez15:12:01

Well, that’s what I am doing now. It works. I was thinking it would be more convenient for my use case if the test-runner for the the “using” project would just pick up the tests of the library and run them as well. I might have misconfigured something when trying because only changes to the implementation of the library triggers shadow to rebuild, changes to the tests don’t…

pez15:12:51

(The misconfiguration is about my attempts to get the tests to run unified in the using app. I have the library tests auto-loaded with the separate test watcher way of doing things.)

thheller15:12:26

well are the tests on the classpath of the main project?

thheller15:12:40

if so they should be picked up when using :local/root?

thheller15:12:37

I assume you are talking about a regular :node-test or :browser-test setup in the main project running as a watch?

pez15:12:27

Yes, :node-test . I have this: main-project/shadow-cljs.edn:

{:builds
 {:app {,,,}
  :test {:target  :node-test, :output-to "target/test/test.js"
         :autorun true}}
 :deps {:aliases [:dev :test]}}

main-project/deps.edn:

:deps {,,,
        library/library {:local/root "../library"}
        ,,,}

library/deps.edn:

{:paths ["src"]
 :aliases {:test {:extra-paths ["test"]
                  :extra-deps {thheller/shadow-cljs {:mvn/version "2.16.7"}}}}}

(The extra-deps is for the separate test runner use case).

thheller15:12:44

well so the tests are not on the classpath?

thheller15:12:11

since they are in the test folder which is not on the classpath when loading in the main project since that doesn't activate the :test alias

pez15:12:07

I though :deps {:aliases [:dev :test]} would activate that.

thheller15:12:53

I actually don't know for sure but I don't think so

thheller15:12:18

this isn't something shadow-cljs can control or change its a tools.deps thing

thheller15:12:38

I would expect that it only activates those aliases for the project but not for any :local/root dependencies

pez15:12:28

I have one more clue. In one of my “using” apps tests are in test/cljs and trying this from there gives me a ExceptionInfo: Resource does not have expected namespace error from shadow-cljs.

thheller15:12:59

same classpath issue if the paths don't match the expected names

pez16:12:04

Yes, but it seems that the alias is active, doesn’t it? I’ll ask in #tools-deps and see if someone have an idea. It’s not a big issue, running a separate test watcher works and has its advantages.

thheller16:12:27

just open a REPL on the main project and run ( "one/of_your_tests.cljs")

thheller16:12:19

in general I'd recommend running tests in the library itself

pez16:12:18

Thanks. I’ll stick with that.

2021-12-07

Channels