@posthog/cli 0.11.3 → 0.13.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 +16 -0
- package/README.md +24 -2
- package/lib/posthog-api-cli.mjs +435 -87
- package/npm-shrinkwrap.json +2 -2
- package/package.json +2 -2
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,21 @@
|
|
|
1
1
|
# posthog-cli
|
|
2
2
|
|
|
3
|
+
## 0.13.0 — 2026-08-18
|
|
4
|
+
|
|
5
|
+
### Minor changes
|
|
6
|
+
|
|
7
|
+
- [f0be634b15f](https://github.com/PostHog/posthog/commit/f0be634b15fbf374bf90db01dfbd9023f9db6536) Add `--release-mode` to `proguard upload`, matching `sourcemap upload`. `symbol-set` (the default) keeps stamping the release onto the uploaded mapping. EXPERIMENTAL `event` creates the release but leaves the mapping unbound, so each event resolves its own release from the app version and namespace the SDK already sends. A map id is derived from the mapping's own content, so this keeps one symbol set for a mapping that several releases share. Also settable via `POSTHOG_RELEASE_MODE`. — Thanks @ablaszkiewicz!
|
|
8
|
+
|
|
9
|
+
## 0.12.0 — 2026-08-18
|
|
10
|
+
|
|
11
|
+
### Minor changes
|
|
12
|
+
|
|
13
|
+
- [45016b12515](https://github.com/PostHog/posthog/commit/45016b12515b58f68ad22f1a0c053c39e2fd97b8) Add `posthog-cli release resolve`, which prints the id of the release the current build belongs to and creates the release if it doesn't exist yet. Only the id goes to stdout, so `RELEASE_ID=$(posthog-cli release resolve)` works; `--json` prints the whole release. It resolves the same release `sourcemap inject` would, so a bundler plugin that injects the release id into chunks itself lands on the same row. When nothing identifies a release, it prints nothing and exits `0`. `--dry-run` skips it, since resolving a release can create one. — Thanks @ablaszkiewicz!
|
|
14
|
+
|
|
15
|
+
### Patch changes
|
|
16
|
+
|
|
17
|
+
- [90730d20684](https://github.com/PostHog/posthog/commit/90730d206846ba073611c5ed103536ddd2828943) Delete CSS source maps and remove their sourceMappingURL comments after upload — Thanks @marandaneto!
|
|
18
|
+
|
|
3
19
|
## 0.11.3 — 2026-08-17
|
|
4
20
|
|
|
5
21
|
### Patch changes
|
package/README.md
CHANGED
|
@@ -34,6 +34,7 @@ Commands:
|
|
|
34
34
|
hermes Upload hermes sourcemaps to PostHog
|
|
35
35
|
proguard Upload proguard mapping files to PostHog
|
|
36
36
|
symbol-sets Upload, download, and manage symbol sets
|
|
37
|
+
release Look up the release a build belongs to
|
|
37
38
|
api Agent-first PostHog API tools
|
|
38
39
|
help Print this message or the help of the given subcommand(s)
|
|
39
40
|
|
|
@@ -43,7 +44,7 @@ Options:
|
|
|
43
44
|
--skip-ssl-verification Skip SSL certificate verification when talking to the PostHog API. Use only with self-signed certificates
|
|
44
45
|
--rate-limit <RATE_LIMIT> Set the number of requests per minute for the Posthog API Client [env: POSTHOG_CLIENT_RATE_LIMIT=]
|
|
45
46
|
--dotenv-file <PATH> Load PostHog credentials from this dotenv-style file when not present in the process environment. Prefer this over the `--env-file` alias: the npm package runs the binary through a `node` wrapper, and Node's own built-in `--env-file` flag intercepts that spelling. Also settable as `POSTHOG_CLI_DOTENV_FILE`, for callers that control the environment but not the command line (e.g. an Xcode build phase invoking the iOS SDK's upload-symbols.sh) [env: POSTHOG_CLI_DOTENV_FILE=]
|
|
46
|
-
--dry-run[=<DRY_RUN>] Skip artifact processing and upload (sourcemap, dSYM, hermes, proguard) without contacting PostHog or requiring credentials. Intended for CI gates that bundle to catch regressions but must not (or cannot) upload. Not for release builds. Pass it before the subcommand (`posthog-cli --dry-run hermes upload ...`) or set `POSTHOG_CLI_DRY_RUN`. This is distinct from the `exp endpoints` `--dry-run`, which previews endpoint changes [env: POSTHOG_CLI_DRY_RUN=] [default: false] [possible values: true, false]
|
|
47
|
+
--dry-run[=<DRY_RUN>] Skip artifact processing and upload (sourcemap, dSYM, hermes, proguard, release) without contacting PostHog or requiring credentials. Intended for CI gates that bundle to catch regressions but must not (or cannot) upload. Not for release builds. Pass it before the subcommand (`posthog-cli --dry-run hermes upload ...`) or set `POSTHOG_CLI_DRY_RUN`. This is distinct from the `exp endpoints` `--dry-run`, which previews endpoint changes [env: POSTHOG_CLI_DRY_RUN=] [default: false] [possible values: true, false]
|
|
47
48
|
-h, --help Print help
|
|
48
49
|
-V, --version Print version
|
|
49
50
|
```
|
|
@@ -89,10 +90,30 @@ POSTHOG_CLI_SOURCEMAP_UPLOAD_CONCURRENCY=32 npm run build
|
|
|
89
90
|
|
|
90
91
|
The CLI flag takes precedence over the environment variable. Both require a value greater than zero. This setting applies only to plain sourcemap uploads; other CLI concurrency remains unchanged.
|
|
91
92
|
|
|
93
|
+
## Resolving a release
|
|
94
|
+
|
|
95
|
+
`posthog-cli release resolve` prints the id of the release the current build belongs to, creating the release if it doesn't exist yet.
|
|
96
|
+
The upload commands do this for you, so reach for it when something else needs the id: a bundler plugin that injects the release into your chunks itself, or a deploy script that wants to record which release it shipped.
|
|
97
|
+
|
|
98
|
+
```bash
|
|
99
|
+
posthog-cli release resolve --release-name my-app --release-version 1.4.0
|
|
100
|
+
01a0002e-93b5-0000-24cf-fc02638acd46
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
Only the id goes to stdout, so `RELEASE_ID=$(posthog-cli release resolve)` works.
|
|
104
|
+
Pass `--json` to get the whole release, including its hash id and the version that git or CI metadata filled in.
|
|
105
|
+
|
|
106
|
+
Both `--release-name` and `--release-version` are read from git or CI metadata when you leave them out.
|
|
107
|
+
When neither the flags nor that metadata identify a release, the command prints nothing (or `null` with `--json`) and exits `0`, so a build can carry on without one.
|
|
108
|
+
A failed lookup exits non-zero instead.
|
|
109
|
+
|
|
110
|
+
Add `--build` to give a build number its own release: it is packed into the version, so `--release-version 1.4.0 --build 42` resolves to a different release than `--release-version 1.4.0` alone.
|
|
111
|
+
|
|
92
112
|
## Skipping uploads (dry run)
|
|
93
113
|
|
|
94
114
|
Pass `--dry-run` before the subcommand (`posthog-cli --dry-run hermes upload ...`), or set `POSTHOG_CLI_DRY_RUN=true`, to turn the upload commands — `sourcemap`, `dsym`, `hermes`, and `proguard` — into a no-op.
|
|
95
|
-
|
|
115
|
+
`release resolve` is skipped too, since resolving a release can create one.
|
|
116
|
+
The CLI logs what it skipped and exits `0` without contacting PostHog or requiring credentials.
|
|
96
117
|
(This top-level flag is separate from the `exp endpoints` `--dry-run`, which previews endpoint changes.)
|
|
97
118
|
|
|
98
119
|
This is meant for CI gates that still want to run the bundling step (to catch Metro/Hermes or sourcemap regressions) but must not — or cannot — upload artifacts, for example pull-request checks that don't have PostHog credentials.
|
|
@@ -110,6 +131,7 @@ Commands require different API scopes. Make sure to set these scopes on your per
|
|
|
110
131
|
| `sourcemap` | `error_tracking:write` |
|
|
111
132
|
| `symbol-sets` | `error_tracking:write` |
|
|
112
133
|
| `dsym` | `error_tracking:write` |
|
|
134
|
+
| `release` | `error_tracking:write` |
|
|
113
135
|
| `exp endpoints list/get/pull` | `endpoint:read` |
|
|
114
136
|
| `exp endpoints push` | `endpoint:write`, `insight_variable:write` |
|
|
115
137
|
| `exp endpoints run` | `query:read` |
|