Running things.

[pixeleet]

It's quite recent that deno has introduced task runner as a thing.

My first impression is that it's more convenient than remembering a bunch of commands, but it gets quite clunky, see example below that I have for functional.

{
  "tasks": {
    "build": "deno task clean && mkdir -p out/deno && deno bundle mod.ts > out/deno/lib.js",
    "build:npm": "deno run -A --unstable ./scripts/build_node.ts $(cat VERSION)",
    "coverage": "deno coverage --unstable ./coverage --lcov > coverage/lcov.info && genhtml coverage/lcov.info  --output-directory coverage",
    "clean": "rm -rf out coverage",
    "test": "deno task clean && deno test -A --unstable --coverage=coverage",
    "version": "/Users/davidpeter/Workspace/kittenpilez/semantic-release-tooling/out/srt-aarch64-apple-darwin"
  }
}

In contrast I also have made a makefile that I've defaulted to using for deno projects which I do find cleaner, along the lines of

.PHONY: coverage
run_flags = -A --unstable
cov_dir = coverage
cov_file = ./$(cov_dir)/lcov.info

build:
	rm -rf out/deno 
	mkdir -p out/deno 
	deno bundle mod.ts > out/deno/lib.js

build-node:
	deno run $(run_flags) ./scripts/build_node.ts $(cat VERSION)

coverage:
	deno coverage --unstable ./$(cov_dir) --lcov > $(cov_file)
	genhtml $(cov_file) --output-directory $(cov_dir)

test:
	rm -rf $(cov_dir)
	deno test $(run_flags) --coverage=$(cov_dir) testing

However makefiles were not really made for running tasks. Wonder which one you prefer.

[baetheus]

This will be done in #4 and wrapped in a nix flake.

[baetheus]

We have a dnt script in the scripts directory. However, I've had some type issues when trying it out, so I'm not in on a deno alias for it. Additionally, there is a coverage script in scripts that can be run with ./scripts/coverage.sh that runs both the tests and coverage. Because our primary exports are all in the root directory of this project I think it's important to have a really good reason to add additional files there. So far we have gotten away with no deno.json file and to add it just for another layer of indirection seems unnecessary and ultimately a net negative. If there comes a point where there are more than two regular contributors and getting contributors to test locally is hard (deno test works too), then I think we could start by editing the README.

Lately, I've been on the fence with automated versioning. I recently did some side work for an old employer where I had set up conventional commits with automated semver and in the year I was gone the version and commit messages were all over the place. Even when I've been working with the node tools for it I have run into regular issues where I have to dry run to see what the tool will do. This has led me to the place where I'm already manually versioning fun and it's quite easy to do so. Thus, I think I'll keep conventional commits, but I'll manage the release versions myself. This seems to be both the easiest and most flexible approach.

So, in summary we have four tasks: tests, coverage, versioning, and building for node. Tests and coverage are in a good place, versioning will continue to be manual, and building for node needs work and then inclusion as a package in flake.nix.

We could create a package in flake.nix that does coverage, but I honestly think simplest is best here. Either deno test for running the test suite or ./scripts/coverage.ts for running tests with coverage.