Fork me on GitHub
#shadow-cljs
<
2022-02-15
>
barrell07:02:51

Hey, I’m getting a weird error when adding a dependency to a project with custom [:js-optons :js-package-dirs]. I’m providing absolute paths to files that exist, but for some reason I am getting the follow error on every build ~ even though it immediately succeeds afterwards. I’ve tried trashing .shadow-cljs and emptying the trash but that doesn’t seem to fix it

[CLJ] [:browser] Build failure:
[CLJ] The required JS dependency "faunadb/dist/faunadb" is not available, it was required by "routes/index.cljs".
[CLJ]
[CLJ] Dependency Trace:
[CLJ]   captain/loader/index.cljs
[CLJ]   captain/loader/router.cljs
[CLJ]   captain/manifest.cljs
[CLJ]   routes/index.cljs
[CLJ]
[CLJ] Searched for npm packages in:
[CLJ]   /Users/barrell/.Trash/.captain 17-47-55-522/node_modules
[CLJ]
[CLJ] See: 
[CLJ]
[CSS] Done in 47ms.
[CLJ] [:browser] Build completed. (217 files, 2 compiled, 0 warnings, 0,20s)

barrell07:02:17

and idea why it’s looking in my .Trash?

thheller07:02:27

what :js-package-dirs did you set? maybe there is a symlink or so?

thheller07:02:12

maybe you deleted the dir while shadow-cljs was running? no clue otherwise

barrell08:02:09

ahhhh yes one of them is probably symlinked

barrell08:02:57

strange that it failes then succeeds everytime though?

thheller17:02:02

yeah dunno. I don't have a clue how you end up loading things from .Trash

😂 1
niwinz15:02:57

Hello @thheller, I have observed that in some shadow-cljs version (some time ago), the development build started generating a single file per module that makes the deveploment build load much faster on browser than previous approach (loading each file). But I have noticed that webworker module still uses the old approach, loading each file separatelly. Is it intentionally? In any case, thank you very much for all your work in shadow-cljs.

thheller17:02:13

I can't remember details but I believe I did some tests with webworkers and the performance didn't differ that much. since it doesn't block the main thread it didn't seem important to use the new method there too

thheller17:02:21

but it could certainly be added there as well

niwinz19:02:01

Hmm, in big projects, the performance is very noticeable. On http://penpot.app project, webworker loads at least 900 files and loading that files takes 12s, of total 15.66s and it is pretty noticeable on first load or forced refresh. I think that having the same approach on webworker will make a difference also. Additionally as context info, we try to make some tests using cypress, but loading a page that loads the webworker module almost always takes too much time that timeouts (with already increased timeout, the things in cypress looks like takes longer to finish all the requests, for now we using advanced build for passing tests but it is very painful on modify->run test iteration because of expected long compile times).

thheller19:02:51

feel free to open an issue about this. maybe I can take a look over the weekend