Closed thatismatt closed 6 years ago
I don't remember why node struggles with relative/absolute paths. Did you try using :asset-path
before :exec-dir
?
Changing the :asset-path
means the test code loads and runs. But this doesn't fix my issue which is that I want the cwd of the node process when running the tests to be "resources/public". My tests depend on this (we verify our config files as part of the tests, arguably this is bad practise, but it is a nice safety check for the CD system).
I know that there were (still are?) issues in compiling cljs to target node, in particular I've hit this issue (https://dev.clojure.org/jira/browse/CLJS-1444) before. But in this case I don't believe this is the fault of the cljs compiler.
So perhaps I should rephrase the bug/feature:
I'd like a way to change the current working directory for the node process that runs the tests. I had assumed that I could do this with :exec-dir
. Setting :exec-dir
does change the current working directory of the node process, but doesn't change the argument (file name of the test js script, test-id.js in my case) passed to node (in my case doo shells out to node resources/public/test-id.js
but because I have set :exec-dir
to resources/public
this should actually be: node test-id.js
BTW doo is awesome, and I'd be happy to put some effort in to seeing this fixed. I noticed the discussions here: https://github.com/bensu/doo/pull/69 & https://github.com/bensu/doo/pull/77 where you say "We shouldn't expose :exec-dir. As it is right now it is only usable from boot-cljs-test and I can't begin to imagine the edge cases that could arise from other users.", so I am aware that I am straying off the happy path! But if there is anything that I can help with let me know, I'll probably need some pointers though :)
Do you think the expected behavior should be that :exec-dir
then adjusts the paths of the scripts?
That'd certainly seem intuitive to me.
But I'm happy to be told I'm doing it wrong though! (i.e. that using
:exec-dir
is the wrong approach.)
On 12 Nov 2017 3:36 a.m., "Sebastian Bensusan" notifications@github.com wrote:
Do you think the expected behavior should be that :exec-dir then adjusts the paths of the scripts?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bensu/doo/issues/157#issuecomment-343711082, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEuSEHaSjfHKfoK0UV_3JOm1Yu19iSRks5s1meqgaJpZM4QU44D .
The problem with adjusting the path of the file to be run is that the rest of the paths (internally generated by cljs) will not be updated and that type of inconsistency is hard to resolve. Also, I suspect that changing that behavior would break boot-cljs-test
so I wouldn't recommend it.
If you want to try something less hacky, you can do :path "cd resources/public && node"
If that works, great. Otherwise, I'm out of ideas :)
Thanks @bensu
For others finding this in the future, here is my final solution:
In project.clj
I point at a custom script:
:doo {:paths {:node "scripts/node-doo.sh"}}
The content of the script node-doo.sh
:
#!/bin/bash
TEST_FILE=$(readlink -e $1)
cd resources/public
node $TEST_FILE
The end result of all this is that node is invoked with a filename that works (a fully qualified one in this case) and the cwd is resources/public
.
Finally, it should be noted that :path "cd resources/public && node"
won't work because cd
isn't a command it is a builtin (which is why I used a bash script instead).
Great, thanks for documenting the solution!
The working directory for my app is
resources/public
. I've tried setting:exec-path
like this:The result then of calling
lein doo node test-id
is below (debug is on, you can see the:output-to
value in the shell command):If I run node directly in resources/public everything works correctly.
Which looks to me like the
:exec-dir
config option doesn't account for the location of the:output-to
value. I'm aware that the:exec-dir
option is undocumented, so I'm happy to be pointed at an alternative way to do this.I have a workaround where I'm changing the doo path for node:
This works, but obviously is a bit hacky.
Thanks for this great tool, Matt