Howion's custom (hence quite opinionated) monorepo to manage all of its (public and private) repositories and/or packages. https://www.howion.com/
  • TypeScript 100%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
2026-08-16 14:17:21 +03:00
.mono install and use git lfs 2026-08-16 14:17:21 +03:00
.vscode install and use git lfs 2026-08-16 14:17:21 +03:00
static install and use git lfs 2026-08-16 14:17:21 +03:00
workspaces install and use git lfs 2026-08-16 14:17:21 +03:00
.editorconfig initial commit 2026-07-29 21:56:56 +03:00
.env.example install and use git lfs 2026-08-16 14:17:21 +03:00
.gitattributes install and use git lfs 2026-08-16 14:17:21 +03:00
.gitignore more and better addons 2026-08-09 00:51:48 +03:00
.markdownlint.jsonc more addons for safer and granular control, simple git, cleaner structure 2026-08-06 07:13:27 +03:00
.mono.env.ts install and use git lfs 2026-08-16 14:17:21 +03:00
.mono.ts install and use git lfs 2026-08-16 14:17:21 +03:00
biome.jsonc install and use git lfs 2026-08-16 14:17:21 +03:00
bun.lock install and use git lfs 2026-08-16 14:17:21 +03:00
LICENSE much better cli without chalk 2026-07-30 02:07:01 +03:00
package.json install and use git lfs 2026-08-16 14:17:21 +03:00
README.md overall improvements, more addons, switch to git.howion.com 2026-08-15 15:04:45 +03:00
tsconfig.json overall improvements, more addons, switch to git.howion.com 2026-08-15 15:04:45 +03:00

howionlabsmono

Howion's custom (hence quite opinionated) monorepo to manage all of its (public and private) @howionlabs repositories and/or packages.

Motivation

None of the existing monorepo tools or structures were good enough and always resulted writing custom scripts. Google's Bazel seemed like a solid choice but the complexity and management of it wasn't worth it. Therefore, hereby we represent our custom monorepo (skeleton) by us for us.

This monorepo is currently is being used by us therefore, especially .mono.ts, is subject to change.

Dependencies

In order to work under this monorepo structure, make sure bun and git are installed.

Moreover, existence of fundamental unix commands such as rm, cp and mkdir are assumed.

Addons

  • $author(author: MonoPerson | MonoFormattedPersonText)
  • $biomejs()
  • $contributor(contributor: MonoPerson | MonoFormattedPersonText)
  • $dependency(id: string)
  • $env(...variables: string[])
  • $git(uri: MonoGitURI)
  • $github() Not implemented yet.
  • $keys() Not implemented yet.
  • $license(id: MonoLicenseId)
  • $markdownlint()
  • $npm(name: string)
  • $static(from: string, to?: string, alwaysOverwrite = false)
  • $vscode()

Mono CLI

remold

pull [id]

commit [id]

push [id]

Best Practices

  1. This monorepo supports single branch for managing it's git-tracked entries. By default it uses the current branch of the root (mono) and throws if tracked entries are on different branch.
  2. Each entry must be independent repository in a way that they should be standalone developable assuming access to possibly private packages. Therefore, assume each entry is its own repository and avoid relative file access outside the entry. Note that this monorepo supports monorepo dependencies via Bun workspaces.

Tech Stack

Roadmap

  1. Better mono documentation.
  2. Git branch management.
  3. Better tracking reporting both by mono and git for all workspace directories.
  4. Consider adding .example to mono env schema/builder for .env.example.
  5. bun mono push safety checks.
  6. Better key management via keys addon.
  7. Gitleaks or Betterleaks?
  8. Add cache for faster remold?
  9. Maybe support multiple git remotes? Will probably be abandoned as many git providers provide mirroring.

License

The code related to the monorepo skeleton (which excludes ./zones that contain proprietary code) is licensed under the MIT License.