https://github.com/d3dc/banana
Software is like Bananas. Sometimes you need bunches.
https://github.com/d3dc/banana
monorepos package-management
Last synced: 3 months ago
JSON representation
Software is like Bananas. Sometimes you need bunches.
- Host: GitHub
- URL: https://github.com/d3dc/banana
- Owner: d3dc
- License: mit
- Created: 2022-03-08T04:11:44.000Z (about 3 years ago)
- Default Branch: main
- Last Pushed: 2022-03-20T16:35:03.000Z (about 3 years ago)
- Last Synced: 2025-01-04T03:29:23.989Z (5 months ago)
- Topics: monorepos, package-management
- Language: TypeScript
- Homepage:
- Size: 39.6 MB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Yarn Bunches
Use git to combine multiple repos into a single monorepo.
## Motivation
Organizations have a lot of repos and teams. Sometimes one monorepo isn't enough. Sometimes you need bunches.
Yarn Bunches are a solution for teams looking to stay in sync with "release channels" but also work within a singular monorepo setup.
## Installation
```
yarn plugins import [release url]
```## Commands
```
━━━ Workspace-related commands ━━━━━━━━━━━━━━━━━yarn locate
shows workspace path
━━━ Bunch-related commands ━━━━━━━━━━━━━━━━━━━━━yarn bunch add
Depend on a bunchyarn bunch init
init bunchyarn bunch remove
remove a bunchyarn bunches [--json]
list the active bunchesyarn bunches clean [--full]
clean the active bunchesyarn bunches sync [--json]
sync the active bunches
```## Bunch Spec
A bunch name can be a `github repo`, a `git url`, or a `local path` followed by `#commit-or-branch`
## Configuration
> or how the defaults need to be decided
### Workspace
1. add a new entry to your workspace array: `".bunches/*/packages/*"`
### Assets, Other languages, Dockerfiles
1. create a package.json that is within your workspaces config
1. run yarn install
1. use the .bunches symlink in the package.json directory## "Release Channels"
It doesn't really seem feasible to maintain individually versioned packages with this approach.
The simplest use cases would be to target one of:
- branches that contain packages that all keep their version number in sync
- branches that contain packages that are PR'd in periodically
- branches that contain unique git "cherrypicks"