Reading shared configuration at build time
Why every app in the ecosystem fetches one registry before it builds, and why a failed fetch should fail the build instead of falling back.
I'm M Fikri Marzuki. This is where I write down how the projects in my ecosystem are designed, built and changed: the reasoning, the dead ends and the parts worth keeping.
SampleEntries marked Sample are placeholders. They show how the journal will read, and their dates are illustrative.
Longer pieces worth starting with.
Why every app in the ecosystem fetches one registry before it builds, and why a failed fetch should fail the build instead of falling back.
A dark theme isn't an inverted light theme. Notes on choosing two palettes, checking contrast, and keeping the first paint in the right colours.
Starting a journal with typed data files and a small repository interface, so a database or CMS can arrive later without rewriting the pages.
Everything new, in the order it was written.
Project updateDeveloper Ecosystem1 min readSample
Gateway is the ecosystem's front door. Its updates here will follow destinations, not features.
Journal entry1 min readSample
Why a journal, and what goes in it.
ArticleEcosystem Config2 min readSample
Why every app in the ecosystem fetches one registry before it builds, and why a failed fetch should fail the build instead of falling back.
Project updateEcosystem Config1 min readSample
Each consumer keeps only the fields it needs. Questions worth answering before adding more consumers.
Note1 min readSample
Reduced motion isn't 'no transitions at all'. A short list of what to remove and what to keep.
Dated notes on where each ecosystem project stands.
Gateway is the ecosystem's front door. Its updates here will follow destinations, not features.
Each consumer keeps only the fields it needs. Questions worth answering before adding more consumers.
Before changing how Playnest works offline, write down what a family should expect without a connection.
Short entries written while the work is still in progress.
Commit messages say what changed. Plans say what should change. Neither keeps the part in between: the option that looked right for an afternoon and then didn't. This logbook is for that part.
Renaming a repository is one command. Finding every consumer, sync script, document and memory that still uses the old name is the actual work. A redirect hides the problem until the old name is reused.
The rule worth keeping: one pnpm check per project that runs lint, types, tests, the production build and the browser tests. If it hasn't run since the last change, the honest status is 'not verified yet'.
Browse by subject.
How the pieces of the ecosystem fit together, and why they are split the way they are.
Interfaces, rendering, accessibility and the details people actually touch.
Typography, colour and the decisions behind a visual identity.
Build steps, checks and the small scripts that keep projects honest.
Planning, reviewing and finishing work, one milestone at a time.
Notes from reading, experiments and things that turned out differently than expected.
M Fikri MarzukiFull-Stack Software Engineer
I build the FM Work ecosystem: a set of small, connected web projects that share one registry of facts. The journal keeps the reasoning behind them in one place.