just with standard rules? (think of SemVer but for rules)

[edvardm]

Hi! First off, many thanks for excellent task automation tool!

I've been wanting something like this for long time, but always found any solution
hard to sell, because make is so ubiquitous -- and still great for building, but not that nice for task automation. So what has been my long-standing goal is to get for
developer automation what SemVer did to versioning; it seems like
certain tasks are pretty standard accross projects, but naming differs,
some are missing, some are unnecessarily specific to project etc. Maybe
it would be possible to standardize those?

I also found at least #1765 which seems to be related.

Imagine you knew nothing of the project, even what language it is written in, and you could immediately say <cmd> dev-setup followed by <cmd> test, notice tests pass, and start developing right over. You'd know those rules exist without even looking. Another power of standards is that you can built on top of abstractions; if you'd know that all projects have same tasks, then writing CI/CD actions would become trivial in even more complex projects.

I tried to do something like this this with Make and somewhat succeeded even, but they way arguments are handled in make is not that convenient (and it doesn't support parameters in dependencies, which was one of key things for me in just). So I was thinking of trying to achieve this rather ambitious thing with just; establish a team-wide standard on what tasks should probably exist in any version-contrtolled software project.

I'm thinking of (ab)using allow-duplicate-recipes setting to create a template justfile which would contain sensible default or blank rule for tasks listed below, to help projects become more consistent and easier to work with.

Here's list of suggested rules, based on environment / application type. All rules should be probably idempotent by default:

Development/common

• dev-init: prepare project ready for development
  • should probably do nothing itself but depend on list of rules which do
    the actual work
• build: build the project
  • For interpreted languages it could mean
    installing dependencies and setting up the runtime environment
• test: run automated tests
• lint: run static code analysis and other linting tools
  • consider adding another param to run more thorough checks which
    might have false positives and report much more, but not required to
    pass in say, CI/CD pipeline
• format: automatically format code
  • automated linter fixes are fine too if safe enough
• install: install application
• validate: validate project setup
  • check versions of required software, check for missing thing etc.
    NOT linting per se, but sometimes useful to check for common issues
    in local project setup
• build-docs: generate project documentation
• debug: start the application in debug mode
• prepare-release: prepare new release
• release: create new release

If docker/podman etc is used:

(more agnostic name could be fine to include podman etc, but I can't think of good name here)

• docker-build: build docker image, parameterized for dev and prod versions
• docker-run: run application with docker
• docker-shell: run (application) shell in docker container for debugging
• docker-test: run tests in docker container

Libraries, applications

• publish: publish to a package registry/index
  • consider versioning, tagging, etc
  • consider prompting for confirmation when sensible to do so

Services

• serve: start server
• deploy: deploy the application to a server or cloud
  • consider env param in case of multiple environments,
    also prompting for confirmation when sensible to do so

Other considerations

• ideally one could run all CI tasks locally too, but if that is not the case, then instead of having complex scripts in CI one should consider using existing task name wich prefix ci-, eg. ci-test
• using override mechanism is not optimal in a sense that there is no concept of "template rule", and I'd want it to be possible to list only rules that have an actual implementation . Easiest way could be to have option --skip-empty or similar to skip rules which are empty?

Any thoughts on this? I know it's not strictly specific to just, but I'm also thinking if something like this was baked in just, it could help in people adopting the tool (eg. just init --template common --template service)

Edit: added crude sample based on this at https://gist.github.com/edvardm/dea4c456d0ae6d6627e35eb2362aa729

[bukowa]

TLDR would love to see some examples

[edvardm]

updated doc with link to public Gist. It's not that nice when everything is in single file, maybe once this is bit more fleshed out I could create sample repository with only those files (it could be even a template repo probably, cruft/cookiecutter project etc)