Starting a TypeScript Project in 2021

I have started looking at this for Svelte projects from a post yesterday on non-javascript build tools. Very promising indeed,

I've never moved past tape, have had ava on the list of things to look into for a very long time but seem to always just `yarn add -D tape bogota` (bogota is a library that runs tape in parallel), any real concrete reasons to use ava over tape? the ava guide says this:

> Tape and tap are pretty good. AVA is highly inspired by their syntax. They too execute tests serially. Their default TAP output isn't very user-friendly though so you always end up using an external tap reporter.

Nicer looking test output and serial execution seem to be the issues here, but I actually like the serial execution bit because it lets you write some messier tests (some that re-use a local test DB let's say) before you straighten up and write shared-nothing test-suites that can run in isolation (spin up a DB container/make a db-per-test-suite/etc).

I really recommend getting comfortable with make -- if you know just enough to be dangerous (PHONY targets, regular targets, ifeq, ?=), it can be an incredibly useful tool, and unify control/operations across projects.

The complexity/required reading that comes with integrating ~5+ individual tools and libraries you have to be aware of across one language can be made a lot easier by using make to do the plumbing between these tools.

Often I find that I need to do some of the following:

- do just a tiny bit of pre-processing

- use two disparate tools which might interact/have an ordering requirement

- alias a simple command for a repetitive task

And it's the case that:

- The tools/libraries I'm using don't have the functionality built in

- I'm not excited about writing a bash script

- A script/build-hook feels too heavy

I find that Makefiles are a really good way to boil down and standardize my builds across projects.

Here's a chunk from a somewhat recent project:

    psql: export DB_CONTAINER_NAME=$(shell $(KUBECTL) get pods -n $(K8S_NAMESPACE) -l component=db -o=name | head -n 1)
    psql:
     $(KUBECTL) exec -it $(DB_CONTAINER_NAME) -n $(K8S_NAMESPACE) psql -- --user $(DB_USER)

And another that's a bit less trendy:

    image: check-tool-docker
     $(DOCKER) build \
     -f infra/docker/Dockerfile \
     -t ${IMAGE_FULL_NAME_SHA} \
     .

    image-publish: check-tool-docker
     $(DOCKER) push ${IMAGE_FULL_NAME_SHA}

    image-release:
     $(DOCKER) tag $(IMAGE_FULL_NAME_SHA) $(IMAGE_FULL_NAME)
     $(DOCKER) push $(IMAGE_FULL_NAME)

And earlier in the file is the actual language-specific stuff:

    lint: check-tool-yarn
     $(YARN) lint

Yeah, all I'm doing is just calling through to yarn here but the nice thing is that `lint` is a pretty common target from project to project, so most places `make lint` will do what I think it is going to do.

And if you're wondering what the check-tool- targets are like:

    check-tool-yarn:
    ifeq (,$(shell which $(YARN)))
     $(error "yarn not installed (see https://yarnpkg.com)")
    endif

I will warn that there are people with Makefile PTSD, but I am finding a lot of value from it these days, would encourage people to take a look. If you're really ready for some fun check out recursive make -- managing and orchestrating subprojects is really really easy (and you don't have to care what the sub project is written in at the top level).

AVA is great, I use it on a few projects and even developed a simple HTTP record/replay add-on for it. I'd say it's good for smaller projects.

One huge benefit of Jest though is the built-in mocking, including module mocking. This stuff is BYO in AVA. Module mocks in particular can be quite annoying to set up, so it's really nice that Jest pulls them all together in one cohesive package.

At what point does the complexity outweigh the benefits?

Just because someone wants to control a UI element to the nth pixel doesn't mean we should let them do that. At this point I'm thinking it might be less bandwidth, complexity, and easier to maintain to just present a web page as a giant imagemap. SVG, so it scales. With screen-ratio-based media queries rather than guessing DPI based on inaccurate factors like the number of pixels.