@bensandee/tooling 0.14.1 → 0.16.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,22 @@
1
1
  # @bensandee/tooling
2
2
 
3
+ ## 0.16.0
4
+
5
+ ### Minor Changes
6
+
7
+ - b3e6d83: Redesign as conventions-first tool: auto-detect project structure, CI platform, project type, and Docker packages from the filesystem. `.tooling.json` now stores overrides only. Replace `repo:init`/`repo:update`/`repo:check` with idempotent `repo:sync` (and `repo:sync --check`). Docker packages are discovered by convention (`Dockerfile` or `docker/Dockerfile` in package dirs) instead of requiring explicit config. First-run prompts reduced to release strategy, CI platform (if not detected), and formatter (if Prettier found).
8
+
9
+ ## 0.15.0
10
+
11
+ ### Minor Changes
12
+
13
+ - 2ef37e2: Add `docker:build` and `docker:publish` CLI commands. Packages declare a `docker` field in their `package.json` with `dockerfile` and `context`, and the tooling handles `docker build` with the correct image name (`{repo}-{package}`). `docker:build --package .` enables a per-package `image:build` script for local testing. `docker:publish` builds all images, then tags/pushes them with semver variants (latest, vX.Y.Z, vX.Y, vX) from each package's own version. Also adds a deploy workflow generator (`setupDocker` config option) that emits a CI workflow triggered on version tags.
14
+ - c09d233: Combine CI and release workflows for changesets strategy into a single check.yml with release job gated on check success
15
+
16
+ ### Patch Changes
17
+
18
+ - 6cae944: Prompt to overwrite outdated release workflows during repo:update instead of only merging missing steps
19
+
3
20
  ## 0.14.1
4
21
 
5
22
  ### Patch Changes
package/README.md CHANGED
@@ -8,19 +8,33 @@ CLI to bootstrap and maintain standardized TypeScript project tooling.
8
8
  pnpm add -D @bensandee/tooling
9
9
 
10
10
  # Or run directly
11
- pnpm dlx @bensandee/tooling repo:init
11
+ pnpm dlx @bensandee/tooling repo:sync
12
12
  ```
13
13
 
14
+ ## Conventions
15
+
16
+ The tool auto-detects project structure, CI platform, project type, and Docker packages from the filesystem. `.tooling.json` stores **overrides only** — omitted fields use detected defaults. Runtime commands (`docker:build`, `checks:run`, `release:changesets`) work without running `repo:sync` first.
17
+
18
+ | Convention | Detection | Default | Override via |
19
+ | ----------------- | ----------------------------------------------------- | ---------------------------------------- | ------------------------------------ |
20
+ | Project structure | `pnpm-workspace.yaml` present | `single` | `structure` in `.tooling.json` |
21
+ | CI platform | `.github/workflows/` or `.forgejo/workflows/` dir | `none` | `ci` in `.tooling.json` |
22
+ | Project type | Dependencies in `package.json` (react, node, library) | `default` | `projectType` in `.tooling.json` |
23
+ | Docker packages | `Dockerfile` or `docker/Dockerfile` in package dirs | — | `docker` map in `.tooling.json` |
24
+ | Formatter | Existing prettier config detected | `oxfmt` | `formatter` in `.tooling.json` |
25
+ | Release strategy | Existing release config detected | monorepo: `changesets`, single: `simple` | `releaseStrategy` in `.tooling.json` |
26
+
14
27
  ## CLI commands
15
28
 
16
29
  ### Project management
17
30
 
18
- | Command | Description |
19
- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
20
- | `tooling repo:init [dir]` | Interactive setup wizard. Flags: `--yes` (accept defaults), `--no-ci`, `--no-prompt`. Saves choices to `.tooling.json`. |
21
- | `tooling repo:update [dir]` | Add missing config files (never overwrites existing files). |
22
- | `tooling repo:check [dir]` | Dry-run drift detection. Exits 1 if files would change. CI-friendly. |
23
- | `tooling checks:run` | Run project checks (build, typecheck, lint, knip, test). Flag: `--fail-fast`. |
31
+ | Command | Description |
32
+ | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
33
+ | `tooling repo:sync [dir]` | Detect, generate, and sync project tooling (idempotent). First run prompts for release strategy, CI platform (if not detected), and formatter (if Prettier found). Subsequent runs are non-interactive. |
34
+ | `tooling repo:sync --check [dir]` | Dry-run drift detection. Exits 1 if files would change. CI-friendly. |
35
+ | `tooling checks:run` | Run project checks (build, typecheck, lint, knip, test). Flag: `--fail-fast`. |
36
+
37
+ **Flags:** `--yes` (accept all defaults), `--no-ci`, `--no-prompt`, `--eslint-plugin`
24
38
 
25
39
  ### Release management
26
40
 
@@ -32,9 +46,97 @@ pnpm dlx @bensandee/tooling repo:init
32
46
  | `tooling forgejo:create-release` | Create a Forgejo release from a tag. |
33
47
  | `tooling changesets:merge` | Merge a changesets version PR. |
34
48
 
49
+ ### Docker
50
+
51
+ | Command | Description |
52
+ | ------------------------ | --------------------------------------------------- |
53
+ | `tooling docker:build` | Build Docker images for discovered Docker packages. |
54
+ | `tooling docker:publish` | Build, tag, and push Docker images to a registry. |
55
+
56
+ Docker packages are discovered automatically. Any package with a `Dockerfile` or `docker/Dockerfile` is a Docker package. Image names are derived as `{root-package-name}-{package-name}`, build context defaults to `.` (project root). For single-package repos, `Dockerfile` or `docker/Dockerfile` at the project root is checked.
57
+
58
+ When Docker packages are present, `repo:sync` generates a deploy workflow (`.forgejo/workflows/deploy.yml` or `.github/workflows/deploy.yml`) triggered on version tags (`v*.*.*`) that runs `pnpm exec tooling docker:publish`.
59
+
60
+ #### Overrides
61
+
62
+ To override defaults, add a `docker` entry to `.tooling.json`:
63
+
64
+ ```json
65
+ {
66
+ "docker": {
67
+ "server": {
68
+ "dockerfile": "packages/server/docker/Dockerfile",
69
+ "context": "."
70
+ }
71
+ }
72
+ }
73
+ ```
74
+
75
+ The `context` field defaults to `"."` (project root) when omitted. Versions for tagging are read from each package's own `package.json`.
76
+
77
+ #### `docker:build`
78
+
79
+ Builds all discovered packages, or a single package with `--package`:
80
+
81
+ ```bash
82
+ # Build all packages with docker config
83
+ tooling docker:build
84
+
85
+ # Build a single package (useful as an image:build script)
86
+ tooling docker:build --package packages/server
87
+
88
+ # Pass extra args to docker build
89
+ tooling docker:build -- --no-cache --build-arg FOO=bar
90
+ ```
91
+
92
+ To give individual packages a standalone `image:build` script for local testing:
93
+
94
+ ```json
95
+ {
96
+ "scripts": {
97
+ "image:build": "pnpm exec tooling docker:build --package ."
98
+ }
99
+ }
100
+ ```
101
+
102
+ **Flags:** `--package <dir>` (build a single package), `--verbose`
103
+
104
+ #### `docker:publish`
105
+
106
+ Runs `docker:build` for all packages, then logs in to the registry, tags each image with semver variants from its own `version` field, pushes all tags, and logs out.
107
+
108
+ Tags generated per package: `latest`, `vX.Y.Z`, `vX.Y`, `vX`
109
+
110
+ Each package is tagged independently using its own version, so packages in a monorepo can have different release cadences. Packages without a `version` field are rejected at publish time.
111
+
112
+ **Flags:** `--dry-run` (build and tag only, skip login/push/logout), `--verbose`
113
+
114
+ **Required environment variables:**
115
+
116
+ | Variable | Description |
117
+ | --------------------------- | --------------------------------------------------------------------- |
118
+ | `DOCKER_REGISTRY_HOST` | Registry hostname (e.g. `code.orangebikelabs.com`) |
119
+ | `DOCKER_REGISTRY_NAMESPACE` | Full namespace for tagging (e.g. `code.orangebikelabs.com/bensandee`) |
120
+ | `DOCKER_USERNAME` | Registry username |
121
+ | `DOCKER_PASSWORD` | Registry password |
122
+
35
123
  ## Config file
36
124
 
37
- `repo:init` persists choices to `.tooling.json` at the project root. `repo:check` and `repo:update` read this file to reproduce the same config without re-prompting.
125
+ `.tooling.json` stores **overrides only** — fields where the project differs from what convention/detection produces. A fully conventional project has `{}` or no `.tooling.json` at all.
126
+
127
+ Available override fields:
128
+
129
+ | Field | Type | Default (detected) |
130
+ | -------------------- | ------- | -------------------------------------------------------------------------------- |
131
+ | `structure` | string | `"monorepo"` if `pnpm-workspace.yaml` present, else `"single"` |
132
+ | `useEslintPlugin` | boolean | `true` |
133
+ | `formatter` | string | `"prettier"` if config found, else `"oxfmt"` |
134
+ | `setupVitest` | boolean | `true` |
135
+ | `ci` | string | Detected from workflow dirs, else `"none"` |
136
+ | `setupRenovate` | boolean | `true` |
137
+ | `releaseStrategy` | string | Detected from existing config, else monorepo: `"changesets"`, single: `"simple"` |
138
+ | `projectType` | string | Auto-detected from `package.json` deps |
139
+ | `detectPackageTypes` | boolean | `true` |
38
140
 
39
141
  ## Library API
40
142