16 august, 2026 / color theme: ef-spring
People maintain their wiki/Zettelkasten in Obsidian or in org-mode files. It helps to prepare for interviews, to find needed CLI commands, to store credentials to their personal servers and for lots of other stuff.
Yet it's not common to store code in such wiki projects. I have lots of unfinished pet projects and little scripts, and I'm trying new libraries all the time. It'd be cool to keep final results in this wiki and build new stuff upon that, even if the project itself won't be released.
My idea is: make a monorepo with all the code, grow the monorepo, and grow new projects from it.
These days, all the code I write is in Clojure and ClojureScript. REPL feels natural: it's like using surgeon's scissors instead of a sword for experimenting with the code, and a dynamic language helps to write scripts that target CLI.
As for the monorepo structure, I only know one architecture called Polylith. It allows you to extract modules into components and reuse them in the new projects.
Polylith is an architecture, and it can be applied in any language.
If you don't want to use Clojure, then most probably you don't know it any other language will do, good candidates are Python and JS, and in general several languages could be used together.
Below is an example of Polylith architecture in my monorepo.
The root of Polylith repositories looks like this:
$ tree -L 1
.
├── components
├── bases
├── projects
├── development
├── build.clj
├── deps.edn
├── Makefile
├── package.json
├── readme.md
└── workspace.edn
It consists of 4 directories:
components are the reusable modules, for example:
bases directory has base blocks for the projects. Every base glues together several components and defines the public API for them.
base block itself consists only of the interface and leaves all the implementation to the components.projects disectory usually consists of service files that help to build the project from several components and one base block.Also, the root contains service files such as deps.edn for Clojure dependencies.
Makefile and build.clj help to build and test the projects,
and package.json is needed by ClojureScript.
workspace.edn stores metadata for the Polylith CLI command.
Polylith has a CLI tool, but it's entirely optional.
In the monorepo I use it to create new components.
Polylith allows you to migrate existing projects into the monorepo incrementally.
First, you need to create a base block, clone everything you have, and fix the build.
That's called a "fat base", since it's not split into components yet. Then you can split the block further into the components. To me, I've only recently finished the migration, and I haven't extracted lots of components yet:
$ tree -L 1 ./components ./components └── postman
postman stores a counterpart for curl/Postman tools for invoking REST services via the REPL.
The bases directory looks like this:
$ tree -L 1 ./bases ./bases ├── clj_scraper ├── clj_tasks ├── doodle_editor ├── fe_experiments └── truth_or_dare_clj
Here, fe_experiments contains this site written in ClojureScript, that was a way for me to learn DOM and how to control it (DOM API is surprisingly imperative and strange to use for declarative HTML pages).
If I need it again, I could either extract a component or grep usage examples.
clj_tasks is a monorepo from the pre-Polylith era: Advent of Code, LeetCode and Clojure Camp problems, Jupyter Notebooks for Deno TS runtime,
and a presentation about gorillas written in Clojure's Jupyter Notebook counterpart - the clerk library:
$ tree -L 1 ./bases/clj_tasks/src/snyssfx/clj_tasks/ ./bases/clj_tasks/src/snyssfx/clj_tasks/ ├── aoc2024 ├── aoc2025 ├── clojure_camp ├── common ├── curl_command.go ├── di ├── external_ip.go ├── gm.clj ├── gm.sql ├── gorillas.clj ├── hs.clj ├── leetcode ├── logic ├── lucky_tickets.clj ├── mb ├── our_mathematical_universe ├── other ├── portal.clj ├── test_deno.ipynb └── vi.clj
In projects, I have several projects, for example, the site fe_experiments looks like this:
$ tree -L 1 ./projects/fe_experiments ./projects/fe_experiments ├── deps.edn ├── node_modules ├── package.json ├── package-lock.json ├── shadow-cljs.edn └── target
Here I have the files with JS and CLJS dependencies, node_modules, and a bundled site in target for copying it to the server after the build.
It's convenient to have everything in one place, and the dynamic interactive programming language and the REPL help a lot.
The next step would be to join the monorepo with my wiki and dotfiles.
Programming with LLMs also benefits from the setup, as you don't need to regenerate a scaffold every time, and all the components are already tested in production.
If you want to publish a project's code, or collaborate with another person on the project and don't expose other projects, it's easy to copy-paste the project into a new Polylith monorepo and start from there.