Canonical tool versions on dev machines: Declaration, Automation, Integration, Documentation
Motivation: To upgrade node, I used nvm, but then I had to edit package.json and .gitlab-ci.yml, and then I saw that .tool-versions still had node 18. I then saw that @yala recommended asdf, and I think it's cool to make such a tool a requirement for devs. I know have been using a similar thing called elm-tooling for my recent elm projects, and I think it's cool.
(1)
As a developer in the team pulling a new version of the dev branch,
I want my machine to automatically bump my tools to the right version
So that I don't need to upgrade manually
(2)
As a developer in the team merging an upgrade,
I want to set the version of any tool that is required for the build to succeed at a single location
So that the version of a tool declared in one config file never diverges from other declarations
(3)
As an onboarding developer in the team,
I want my environment to be prepared for (1) and (2)
So that I never struggle with out-of-sync tool version
(4)
As a developer in the team,
I need a documentation that clearly states how the dev and build processes use and install tools
So that I know how the development tools interact with my machine and my userspace configuration (nvm, node,...)
-
-
SINGLE METATOOL: We select a single metatool to manage versions of all vital tools (probably asdf, right @yala ?)
-
SINGLE CONFIG LOCATION: We configure the metatool such that there is only one place where we bump version numbers of our tools
-
COMPLETE AUTOMATION: Any build (local dev|build, CI, tests, etc.) honors the declared versions of the tools, and bumps or downgrades automatically
-
COMPLETE INTEGRATION: The metatool is a dev dependency of the project and will be installed by any developer (either manually or through pnpm ci)
-
COMPLETE DOCUMENTATION: The configuration of tool versions is documented in the README and/or CONTRIBUTING document
-
Also see #19 (closed)
Also see #17