Welcome home: bonapasogit-dev Organization 🏛️💻

bonapasogit-dev was created as an engineering organization with a social conscience. The spirit is simple: technology should scale capability, not ego.

🛠️ Our Three Pillars

  • Somba Marhula-hula (Maintainer/Contributor Priority)

    We hold every contribution in the highest regard. Community feedback is the “blessing” that empowers our projects to grow and improve.

  • Elek Marboru (User Experience)

    We are committed to serving our users with approachable documentation, solution-oriented support, and intuitive libraries.

  • Manat Mardongan Tubu (Internal Quality & Stability) We practice great care in maintaining code quality. Every pull request is reviewed meticulously to ensure the integrity and stability of the system.

Our core values are inspired by Indonesian principles:

  • Gotong royong: collaboration over individual heroics.
  • Manfaat: build tools that bring practical benefit.
  • Amanah: be responsible in design, release, and maintenance.
  • Rendah hati: stay humble, let the work speak.

This is why our first open source step is a monorepo tooling project. It helps teams work together with shared standards and shared ownership.

Introduce bonatools: A master collection of Node.js libraries, tools, and scripts by bonapasogit-dev. The backbone of our digital craft.

2. Why This Project Exists

bonatools is not only a technical monorepo. It is the first open source initiative under bonapasogit-dev, and it carries two goals at the same time:

  • Build reliable, reusable engineering tools for real teams.
  • Keep a social foundation and philosophy rooted in Indonesian values.

Many open source projects focus only on code quality. We want both: quality and character.

3. What bonatools Contains

bonatools is a TypeScript monorepo using npm workspaces and Turbo for task orchestration.

Current packages include:

  • @bonapasogit-dev/jwt-manager: JWT lifecycle and token state utilities.
  • @bonapasogit-dev/responder: standardized API response builder and handler.
  • @bonapasogit-dev/partukkang: internal CLI for package/tool workflows for managing bonatools.
  • @bonapasogit-dev/http-client: planned package.

This setup gives one source of truth for standards, while allowing packages to evolve with clear boundaries.

4. Why We Chose a Monorepo

We use a monorepo because it supports the way we build:

  • Shared standards for linting, testing, and release.
  • Easier refactor across packages when contracts evolve.
  • Faster CI and local workflows using Turbo caching.
  • Better collaboration because code and context live together.

Monorepo is not about trend. It is about lowering coordination cost while keeping quality high.

5. Introduce: “Partukkang”

If bonatools is the ecosystem, then partukkang is the operator console.

@bonapasogit-dev/partukkang is the CLI that standardizes how contributors and internal teams interact with the monorepo. Instead of memorizing many custom scripts, developers use one command surface to discover packages/tools, install what they need, configure local setup, and validate environment readiness.

Core capabilities:

  • list: discover available tools, scripts, and packages in one place.
  • install: pull internal packages or tools using consistent options.
  • configure init and configure apply: bootstrap and apply YAML-based local configuration.
  • doctor: run diagnostics and safe auto-fix for common setup problems.

Example flow:

partukkang list packages
partukkang configure init
partukkang configure apply --file partukkang.config.yaml --dry-run
partukkang doctor --fix

This is powerful because it reduces onboarding friction and operational drift across contributors. Everyone follows the same workflow contract.

6. Development Workflow (Contributor to PR)

Our contributor workflow is intentionally simple:

  1. Sync from main and create a focused branch.
  2. Change only what is needed (one package or one concern).
  3. Run package-scoped build/test while iterating.
  4. Run root build/test before opening PR.
  5. Open PR with impact, test evidence, and migration notes when needed.

This keeps pull requests reviewable and safe.

7. Release Philosophy in Monorepo

A common question: in a monorepo, do we release everything together?

For bonatools, the answer is no.

  • Packages are released independently.
  • Root monorepo is private and is not published as a package.
  • We only do coordinated multi-package release when intentionally required.

This model gives us speed without forcing unrelated version bumps.

8. Who Can Publish

Another important governance point:

  • Contributors generally stop at PR and merge.
  • Maintainers handle publishing.
  • Non-maintainer publish is possible only when explicitly authorized and granted registry access.

This protects release consistency and avoids accidental duplicate publishes.

9. Engineering Direction

The long-term direction is clear:

  • Keep APIs small, explicit, and testable.
  • Keep releases predictable with SemVer discipline.
  • Keep contribution flow friendly for first-time contributors.
  • Keep values visible, not only in docs, but also in decisions.

Open source is not just about shipping code. It is about building trust over time.

10. Closing

If you are looking for a modern TypeScript monorepo with clear release boundaries and a human-centered foundation, bonatools is our first step.

We are building this in public with Indonesian-rooted collaboration values, and we welcome contributors who care about both engineering quality and shared impact.