A Turborepo monorepo for MayR Labs JavaScript/TypeScript tooling.
This repository is the home for shared packages, internal tooling, and playgrounds used to build, test, and evolve MayR Labs projects. The goal is to keep reusable logic centralised, iteration fast, and standards consistent.
This repo is intentionally simple and opinionated. It is organised into three top-level areas:
apps/– runnable applications or long‑lived toolspackages/– reusable libraries and CLI packagesplayground/– disposable sandboxes for testing packages in real-world conditions
The README avoids listing individual apps or packages on purpose. Those change. The structure does not.
- Node.js (LTS recommended)
- npm (or the package manager configured for this repo)
Install all dependencies from the repo root:
npm installRun Turborepo tasks:
npm run turboCommon workflows:
npm run build
npm run dev
npm run lint
npm run testTurborepo handles dependency ordering automatically when pipelines are configured correctly.
mayrlabs-js/
apps/
packages/
playground/
turbo.json
package.jsonThe playground/ directory exists purely for fast feedback.
It allows you to:
- Install local packages as if they were published
- Test CLIs interactively
- Reproduce real consumer behaviour without polluting actual apps
Example local install using a file reference:
npm install "@mayrlabs/some-package@file:../../packages/some-package"For smoother iteration, workspace linking is preferred.
Internal packages should usually be consumed via workspace resolution.
Example dependency:
{
"dependencies": {
"@mayrlabs/some-package": "*"
}
}Then install from the repo root:
npm installThis keeps changes flowing instantly without reinstalls.
This repo is designed to work cleanly with Changesets.
Create a changeset:
npx changesetApply version bumps:
npx changeset versionPublish packages:
npx changeset publishFor public scoped packages, ensure the following exists in the package configuration:
{
"publishConfig": { "access": "public" }
}- Scoped packages use
@mayrlabs/* - Prefer small, focused packages over “god modules”
- Avoid circular dependencies
- CLIs must provide a useful
--help
If a tool is added, it should be easy to remove.
- Confirm the package is published and public
- Check
publishConfig.access - Verify the package name exactly (npm is literal-minded)
- File-based installs may require reinstall
- Prefer workspace linking for active development
MIT, unless stated otherwise in a specific package.