the how
how he builds
Nine packages is a catalogue, and a catalogue does not tell you how somebody works; These are the positions the catalogue was built out of; Each one cites something already published, because a principle that cannot point at a consequence is just a preference...
01
a package is an argument you won by writing it
Most opinions about how software should be built are held in a comment thread; The ones worth having are settled by publishing the thing and letting people install it or not; dart_husky is not a port — it is the position that Dart developers deserve the same tooling maturity Node developers have, made concrete enough to `pub add`...
This is also why there is no blog here arguing for any of it; The argument is the package; If it were persuasive only as prose, it would not have been worth the weekend...
argued bydart_huskycommitguard
02
loyal to the problem, not to the stack
Flutter on mobile, Vue and Nuxt on the web, Dart and TypeScript for the tooling around both, C# and Python where they fit better; None of that is a preference list — it is what was in reach when a particular problem needed solving...
The clearest demonstration is the same idea shipped twice; dart_husky and commitguard are one argument — a project should not need a second runtime installed to run a git hook — held in two ecosystems that could not share a line of code; A person loyal to a stack writes that tool once and tells the other ecosystem to switch...
argued bydart_huskycommitguardmoulify
03
solve it once, then install it
Every Flutter project that ships to a browser and a phone rewrites the same breakpoint logic around its navigation; Every Flutter project that needs a contact form drags a backend behind it — an endpoint, a key, a spam filter, a deploy — for three text fields and a send button...
The second time a problem appears is the signal; Not the first: the first time it is just work; The second time it is a missing package, and writing it costs roughly what solving it privately would have cost anyway, with the difference that it stops being your problem afterwards...
argued byadaptive_navbarmb_contact_form
04
say what the data cannot answer
A null is two completely different facts wearing the same clothes; On Android with READ_PHONE_STATE denied, a missing carrier name is recoverable — prompt for it; On iOS 16 and later the same null is permanent, because Apple removed CTCarrier and there is nothing left to ask for; Identical in the payload, opposite in a user interface...
An API that returns both as `null` has handed the caller a decision it had the information to make and chose not to; carrier_info_plus was rewritten from the ground up rather than forked precisely so that every result could carry a support block saying what was answerable and why; Telling those two cases apart is not a feature of that package — it is the reason it exists...
argued bycarrier_info_plus
05
discipline is aesthetic, not bureaucracy
Conventional commits, a linter that runs before the commit rather than in review, dependency updates that arrive as small boring pull requests; None of this is process for its own sake; It is the same attention to form a writer brings to a sentence, applied to a git history that somebody — probably you, in a year — will have to read...
The monorepo this site is built in runs commitguard on itself; The `commitguard.yaml` at its root is what enforced Biome and Conventional Commits on every commit that produced the page you are reading, including this one; A tool its author does not run is a tool its author does not believe...
argued bycommitguardflutter_upgradex
06
a degraded build is still a build
The download figures on this site are read from pub.dev and npm while it is being built; Nothing in that client throws; A registry having a bad thirty seconds must not turn a green pipeline red, and it must not publish a page that quietly says something false instead...
So a failed call leaves its field undefined, a missing figure renders an em dash rather than a zero, and the tally in the hero reports how many packages it actually counted; A partial failure under-reports visibly; The failure mode was chosen before it happened, which is the only time you get to choose it...
argued byutils/registry.ts
07
never make a person the synchronisation point
The four resumes below could each carry an `available: true` flag; It would be one line, and it would be the wrong line — it makes a human being responsible for keeping a claim and a file in agreement, in a repository nobody will reopen for a year; The failure mode is a flag flipped ahead of the file, which is a download link that 404s...
So the build asks the filesystem instead; A PDF dropped into `public/resumes/` appears on the next deploy; One removed disappears the same way; The data file and reality cannot drift, because the data file is not what decides; Wherever a fact is already recorded somewhere, read it from there...
argued bydata/resumes.ts