ghcid VS hadolint

You can use ghcid. It compiles the code, and shows if there are any errors as you save your file. Have two terminals. One for editing your file...other one with ghcid ($ ghcid path/to/filename.hs). Right click on the ghcid terminal and click `always on top`. That way, It will be always visible as you are typing and saving code.

With a combination of ghcid, an hiedb filewatcher and the -fdefer-type-errors flag you can get pretty solid IDE behavior. Currently only ghc 9.4.4 is supported but happy to personally help people set this up if interested!

With an editor integration, you could rig it up to where you could right-click on a Spec, choose "Run spec" from a context menu, and have your editor add that comment to and save dev.hs. Another editor integration could read and parse the contents of ghcid.txt. We have this already for the compiler output, but it doesn't yet parse the test output. But sans an editor integration, you will still see the test output in the console where Ghcid is running.

Sounds like you want ghcid. You can use it run tests on a successful build, and it will watch files in your project and quick-rebuild when there are changes. There shouldn't be any need to modify your Cabal files or test dependencies.

In addition, for Haskell, I usually have ghcid running, which likewise re-runs on every file change, but gives faster feedback about any type errors than the full compiler, and also is configured to evaluate

Have you looked into ghcid? https://github.com/ndmitchell/ghcid

VS Code + Haskell extension is usually best, but ghcid is an alternative which is much simpler, easier to set up, less pretty and powerful but still pretty easy and effective to use. Here's a workflow:

In general, though, I recommend just looking at the cabal files for various libraries and executables. Something like ghcid is good, since it contains a library, an executable, and a test suite.

you should also checkout the ghci vim plugin https://github.com/ndmitchell/ghcid/tree/master/plugins/nvim

To skip the "move your scripts to standalone files" step some devs don't like, consider something like https://github.com/hadolint/hadolint which runs Shellcheck over inline scripts within Containerfiles.

This is neat :)

I love going and making containers smaller and faster to build.

I don't know if it's useful for alpine, but adding a --mount=type=cache argument to the RUN command that `apk add`s might shave a few seconds off rebuilds. Probably not worth it, in your case, unless you're invalidating the cached layer often (adding or removing deps, intentionally building without layer caching to ensure you have the latest packages).

Hadolint is another tool worth checking out if you like spending time messing with Dockerfiles: https://github.com/hadolint/hadolint

With Depot, we make use of two Dockerfile linters, hadolint and a set of Dockerfile linter rules that Semgrep has written to make a bit of a smarter Dockerfile linter.

# Download hadolint wget https://github.com/hadolint/hadolint/releases/download/v2.12.0/hadolint-Linux-x86_64 # Download SHA256 checksum wget https://github.com/hadolint/hadolint/releases/download/v2.12.0/hadolint-Linux-x86_64.sha256 # Validate the checksum sha256sum -c hadolint-Linux-x86_64.sha256 # Make the file executable chmod + ./hadolint-Linux-x86_64 # Rename the file mv hadolint-Linux-x86_64 hadolint

The most common linter I've seen and used it Hadolint, which does: https://github.com/hadolint/hadolint/wiki/DL3002 I didn't bother checking to see if alternatives also support this as well though.

Some discussion on that here:

https://github.com/koalaman/shellcheck/issues/58

The hadolint project does shell checking for Dockerfiles and it uses shellcheck:

https://github.com/hadolint/hadolint

So the approach is definitely feasible, but you do need a new project and probably it needs to be written in Haskell.

how does this compare to something like hadolint?

Also, have you run across Hadolint for linting? https://github.com/hadolint/hadolint