I work with Haskell stack and found the --file-watch opton, but was then surprised that it works for build but not for run. Searching on the web indicates that there are some ways to achieve the effects of stack run --file-watch with other commands (script?), but I could not find a simple, straightforward solution. Is there one?
Use --exec COMMAND [ARGUMENT(S)] for stack build
From stack build --help:
--exec COMMAND [ARGUMENT(S)]
Command and argument(s) to run after a successful build
So, finally
stack build --file-watch --exec COMMAND
The name of executable file is specified in package.yaml (or .cabal)
Related
Is there a way to specify which executable to run (with stack run) when I am working with a Stack multi package project?
My problem was that I was using the package name rather than the executable name in my stack run command:
Wrong: stack run foo
Correct: stack run foo-exe
I am trying to learn how to use stack to build Haskell project. I run from a command line:
stack new helloworld new-template
cd helloworld
stack build
I get
Error parsing targets: The specified targets matched no packages.
Perhaps you need to run 'stack init'?
Any idea? I am on Windows.
Try to upgrade your stack version with stack upgrade, you might be using some outdated or unstable version.
I'm new to yesod and just trying to use stack to build one or two basic sites from the templates but I get an Aeson error when I do. There is a discussion of the error message here [0] but it is apparently fixed in 1.6.1 and I'm using 1.6.3. This is what I'm trying:
$ stack --version
Version 1.6.3
$ stack new yesod-project yesod-sqlite
Downloading template "yesod-sqlite" to create project "yesod-project" in yesod-project/ ...
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- yesod-project/
Selecting the best among 12 snapshots...
* Matches lts-10.5
Selected resolver: lts-10.5
Initialising configuration using resolver: lts-10.5
Total number of user packages considered: 1
Writing configuration to file: yesod-project/stack.yaml
All done.
$ cd yesod-project/
$ stack build
$ stack exec -- yesod devel
Yesod devel server. Enter 'quit' or hit Ctrl-C to quit.
Application can be accessed at:
http://localhost:3000
https://localhost:3443
If you wish to test https capabilities, you should set the following variable:
export APPROOT=https://localhost:3443
Downloading lts-10.5 build plan ...
Downloaded lts-10.5 build plan.
AesonException "Error in $.packages.cassava.constraints.flags['bytestring--lt-0_10_4']: Invalid flag name: \"bytestring--lt-0_10_4\""
Type help for available commands. Press enter to force a rebuild.
[0] https://github.com/commercialhaskell/stack/issues/3634
If you run stack exec -- stack --version I bet you will find that it is older than 1.6.3. You should probably delete the stack binary at stack exec -- which stack
mgsloan's assessment of the cause is correct, at least in my case.
Solution-wise, I'm guessing deleting the stack binary forces it to upgrade. For those who are hesitant to delete stack, stack upgrade did the trick for me.
Getting this issue while trying to run my Yesod application. stack build has already been run and gives no output anymore.
$ stack exec -- yesod devel
Executable named yesod not found on path: ["path/to/app"]
Turns out yeosd-bin needs to be compiled separately.
Running $ stack build yesod-bin solves the issue.
So when running the following command I'm expecting node-sass to compile and start watching. If I have to run a separate node-sass -w command wouldn't I have to include all the same parameters I included on the first? Seems like an odd way of doing things.
node-sass app/styles -o app/styles --source-map true --include-path app/bower_components --quiet --watch
Actually watch triggers compilation each and every time the file changes, as the (sass) documentation states:
You can also tell Sass to watch the file and update the CSS every time the Sass file changes: [...]
However, the documentation says nothing about what happens when the watch process starts, which is what led you to expect it to compile right after being invoked.
It's, for sure, an odd way of doing things.