@whatcha/cli 0.0.0-stage → 0.3.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/LICENSE +202 -0
- package/README.md +345 -2
- package/dist/auth/gotrue-client.js +64 -0
- package/dist/auth/gotrue-client.js.map +1 -0
- package/dist/auth/session.js +147 -0
- package/dist/auth/session.js.map +1 -0
- package/dist/auth/token-store.js +165 -0
- package/dist/auth/token-store.js.map +1 -0
- package/dist/cli.js +134 -0
- package/dist/cli.js.map +1 -0
- package/dist/commands/diaries.js +52 -0
- package/dist/commands/diaries.js.map +1 -0
- package/dist/commands/login.js +292 -0
- package/dist/commands/login.js.map +1 -0
- package/dist/commands/profiles.js +287 -0
- package/dist/commands/profiles.js.map +1 -0
- package/dist/commands/publish.js +81 -0
- package/dist/commands/publish.js.map +1 -0
- package/dist/commands/read.js +77 -0
- package/dist/commands/read.js.map +1 -0
- package/dist/commands/shared-diary.js +255 -0
- package/dist/commands/shared-diary.js.map +1 -0
- package/dist/commands/whoami.js +50 -0
- package/dist/commands/whoami.js.map +1 -0
- package/dist/commands/wiki.js +386 -0
- package/dist/commands/wiki.js.map +1 -0
- package/dist/commands/write.js +106 -0
- package/dist/commands/write.js.map +1 -0
- package/dist/config.js +47 -0
- package/dist/config.js.map +1 -0
- package/dist/errors.js +46 -0
- package/dist/errors.js.map +1 -0
- package/dist/http-client.js +102 -0
- package/dist/http-client.js.map +1 -0
- package/dist/index.js +16 -0
- package/dist/index.js.map +1 -0
- package/dist/lib/append-entry.js +193 -0
- package/dist/lib/append-entry.js.map +1 -0
- package/dist/lib/diary-resolve.js +50 -0
- package/dist/lib/diary-resolve.js.map +1 -0
- package/dist/lib/entry-date.js +96 -0
- package/dist/lib/entry-date.js.map +1 -0
- package/dist/lib/entry-find.js +39 -0
- package/dist/lib/entry-find.js.map +1 -0
- package/dist/lib/image-upload.js +126 -0
- package/dist/lib/image-upload.js.map +1 -0
- package/dist/lib/jwt.js +25 -0
- package/dist/lib/jwt.js.map +1 -0
- package/dist/lib/output.js +29 -0
- package/dist/lib/output.js.map +1 -0
- package/dist/lib/personal-access-token.js +46 -0
- package/dist/lib/personal-access-token.js.map +1 -0
- package/dist/lib/profile-family.js +29 -0
- package/dist/lib/profile-family.js.map +1 -0
- package/dist/lib/publication.js +55 -0
- package/dist/lib/publication.js.map +1 -0
- package/dist/types.js +6 -0
- package/dist/types.js.map +1 -0
- package/package.json +46 -4
package/LICENSE
ADDED
|
@@ -0,0 +1,202 @@
|
|
|
1
|
+
|
|
2
|
+
Apache License
|
|
3
|
+
Version 2.0, January 2004
|
|
4
|
+
http://www.apache.org/licenses/
|
|
5
|
+
|
|
6
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
7
|
+
|
|
8
|
+
1. Definitions.
|
|
9
|
+
|
|
10
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
11
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
12
|
+
|
|
13
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
14
|
+
the copyright owner that is granting the License.
|
|
15
|
+
|
|
16
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
17
|
+
other entities that control, are controlled by, or are under common
|
|
18
|
+
control with that entity. For the purposes of this definition,
|
|
19
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
20
|
+
direction or management of such entity, whether by contract or
|
|
21
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
22
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
23
|
+
|
|
24
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
25
|
+
exercising permissions granted by this License.
|
|
26
|
+
|
|
27
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
28
|
+
including but not limited to software source code, documentation
|
|
29
|
+
source, and configuration files.
|
|
30
|
+
|
|
31
|
+
"Object" form shall mean any form resulting from mechanical
|
|
32
|
+
transformation or translation of a Source form, including but
|
|
33
|
+
not limited to compiled object code, generated documentation,
|
|
34
|
+
and conversions to other media types.
|
|
35
|
+
|
|
36
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
37
|
+
Object form, made available under the License, as indicated by a
|
|
38
|
+
copyright notice that is included in or attached to the work
|
|
39
|
+
(an example is provided in the Appendix below).
|
|
40
|
+
|
|
41
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
42
|
+
form, that is based on (or derived from) the Work and for which the
|
|
43
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
44
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
45
|
+
of this License, Derivative Works shall not include works that remain
|
|
46
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
47
|
+
the Work and Derivative Works thereof.
|
|
48
|
+
|
|
49
|
+
"Contribution" shall mean any work of authorship, including
|
|
50
|
+
the original version of the Work and any modifications or additions
|
|
51
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
52
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
53
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
54
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
55
|
+
means any form of electronic, verbal, or written communication sent
|
|
56
|
+
to the Licensor or its representatives, including but not limited to
|
|
57
|
+
communication on electronic mailing lists, source code control systems,
|
|
58
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
59
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
60
|
+
excluding communication that is conspicuously marked or otherwise
|
|
61
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
62
|
+
|
|
63
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
64
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
65
|
+
subsequently incorporated within the Work.
|
|
66
|
+
|
|
67
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
68
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
69
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
70
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
71
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
72
|
+
Work and such Derivative Works in Source or Object form.
|
|
73
|
+
|
|
74
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
75
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
76
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
77
|
+
(except as stated in this section) patent license to make, have made,
|
|
78
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
79
|
+
where such license applies only to those patent claims licensable
|
|
80
|
+
by such Contributor that are necessarily infringed by their
|
|
81
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
82
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
83
|
+
institute patent litigation against any entity (including a
|
|
84
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
85
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
86
|
+
or contributory patent infringement, then any patent licenses
|
|
87
|
+
granted to You under this License for that Work shall terminate
|
|
88
|
+
as of the date such litigation is filed.
|
|
89
|
+
|
|
90
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
91
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
92
|
+
modifications, and in Source or Object form, provided that You
|
|
93
|
+
meet the following conditions:
|
|
94
|
+
|
|
95
|
+
(a) You must give any other recipients of the Work or
|
|
96
|
+
Derivative Works a copy of this License; and
|
|
97
|
+
|
|
98
|
+
(b) You must cause any modified files to carry prominent notices
|
|
99
|
+
stating that You changed the files; and
|
|
100
|
+
|
|
101
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
102
|
+
that You distribute, all copyright, patent, trademark, and
|
|
103
|
+
attribution notices from the Source form of the Work,
|
|
104
|
+
excluding those notices that do not pertain to any part of
|
|
105
|
+
the Derivative Works; and
|
|
106
|
+
|
|
107
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
108
|
+
distribution, then any Derivative Works that You distribute must
|
|
109
|
+
include a readable copy of the attribution notices contained
|
|
110
|
+
within such NOTICE file, excluding those notices that do not
|
|
111
|
+
pertain to any part of the Derivative Works, in at least one
|
|
112
|
+
of the following places: within a NOTICE text file distributed
|
|
113
|
+
as part of the Derivative Works; within the Source form or
|
|
114
|
+
documentation, if provided along with the Derivative Works; or,
|
|
115
|
+
within a display generated by the Derivative Works, if and
|
|
116
|
+
wherever such third-party notices normally appear. The contents
|
|
117
|
+
of the NOTICE file are for informational purposes only and
|
|
118
|
+
do not modify the License. You may add Your own attribution
|
|
119
|
+
notices within Derivative Works that You distribute, alongside
|
|
120
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
121
|
+
that such additional attribution notices cannot be construed
|
|
122
|
+
as modifying the License.
|
|
123
|
+
|
|
124
|
+
You may add Your own copyright statement to Your modifications and
|
|
125
|
+
may provide additional or different license terms and conditions
|
|
126
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
127
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
128
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
129
|
+
the conditions stated in this License.
|
|
130
|
+
|
|
131
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
132
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
133
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
134
|
+
this License, without any additional terms or conditions.
|
|
135
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
136
|
+
the terms of any separate license agreement you may have executed
|
|
137
|
+
with Licensor regarding such Contributions.
|
|
138
|
+
|
|
139
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
140
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
141
|
+
except as required for reasonable and customary use in describing the
|
|
142
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
143
|
+
|
|
144
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
145
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
146
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
147
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
148
|
+
implied, including, without limitation, any warranties or conditions
|
|
149
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
150
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
151
|
+
appropriateness of using or redistributing the Work and assume any
|
|
152
|
+
risks associated with Your exercise of permissions under this License.
|
|
153
|
+
|
|
154
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
155
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
156
|
+
unless required by applicable law (such as deliberate and grossly
|
|
157
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
158
|
+
liable to You for damages, including any direct, indirect, special,
|
|
159
|
+
incidental, or consequential damages of any character arising as a
|
|
160
|
+
result of this License or out of the use or inability to use the
|
|
161
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
162
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
163
|
+
other commercial damages or losses), even if such Contributor
|
|
164
|
+
has been advised of the possibility of such damages.
|
|
165
|
+
|
|
166
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
167
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
168
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
169
|
+
or other liability obligations and/or rights consistent with this
|
|
170
|
+
License. However, in accepting such obligations, You may act only
|
|
171
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
172
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
173
|
+
defend, and hold each Contributor harmless for any liability
|
|
174
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
175
|
+
of your accepting any such warranty or additional liability.
|
|
176
|
+
|
|
177
|
+
END OF TERMS AND CONDITIONS
|
|
178
|
+
|
|
179
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
180
|
+
|
|
181
|
+
To apply the Apache License to your work, attach the following
|
|
182
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
183
|
+
replaced with your own identifying information. (Don't include
|
|
184
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
185
|
+
comment syntax for the file format. We also recommend that a
|
|
186
|
+
file or class name and description of purpose be included on the
|
|
187
|
+
same "printed page" as the copyright notice for easier
|
|
188
|
+
identification within third-party archives.
|
|
189
|
+
|
|
190
|
+
Copyright [yyyy] [name of copyright owner]
|
|
191
|
+
|
|
192
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
193
|
+
you may not use this file except in compliance with the License.
|
|
194
|
+
You may obtain a copy of the License at
|
|
195
|
+
|
|
196
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
197
|
+
|
|
198
|
+
Unless required by applicable law or agreed to in writing, software
|
|
199
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
200
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
201
|
+
See the License for the specific language governing permissions and
|
|
202
|
+
limitations under the License.
|
package/README.md
CHANGED
|
@@ -1,3 +1,346 @@
|
|
|
1
|
-
#
|
|
1
|
+
# whatcha
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Official command-line client for [what-are-you-do-ing](https://whatareyoudo.ing) --
|
|
4
|
+
the tool an AI agent (or a script) uses instead of automating a browser.
|
|
5
|
+
See `docs/proposals/2026-09-official-cli.md` for why this exists.
|
|
6
|
+
|
|
7
|
+
## Install
|
|
8
|
+
|
|
9
|
+
```
|
|
10
|
+
npx @whatcha/cli <command>
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
or install it once:
|
|
14
|
+
|
|
15
|
+
```
|
|
16
|
+
npm install -g @whatcha/cli
|
|
17
|
+
whatcha <command>
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
Requires Node >= 22 (fetch, `node:util`'s `parseArgs`, and the fixed
|
|
21
|
+
`package.json`'s `"engines"` all assume it).
|
|
22
|
+
|
|
23
|
+
## Commands
|
|
24
|
+
|
|
25
|
+
### `whatcha login`
|
|
26
|
+
|
|
27
|
+
```
|
|
28
|
+
whatcha login --key <personal-access-key> [--json]
|
|
29
|
+
whatcha login [--email <email>] [--password <password>] [--json]
|
|
30
|
+
whatcha login --token <refresh-token> [--json]
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
**For scripts, servers and AI agents, use a personal access key (#1663).**
|
|
34
|
+
Issue one in the app under *Profile → Connected apps and keys* (#1469,
|
|
35
|
+
server side in #1550) -- read-only or read/write, with an expiry -- and
|
|
36
|
+
pass it as `--key`, or set `WHATCHA_KEY` and run `whatcha login`. A key
|
|
37
|
+
handed to `--token` / `WHATCHA_TOKEN` is recognised by its `whatcha_pat_`
|
|
38
|
+
prefix and used as a key too. `login` checks the key with `GET /me`
|
|
39
|
+
before saving it. A key is the Bearer credential itself: it is never
|
|
40
|
+
refreshed, never meets a captcha, and stops working the moment it is
|
|
41
|
+
revoked -- every command then fails with `KEY_REVOKED` (or `KEY_EXPIRED`
|
|
42
|
+
once it expires) and a pointer to where to issue a new one. Explicit
|
|
43
|
+
`--email` / `--password` / `--token` flags win over a `WHATCHA_KEY` left
|
|
44
|
+
in the environment.
|
|
45
|
+
|
|
46
|
+
Signs in and stores the session -- an OS credential store when one is
|
|
47
|
+
available (macOS Keychain via `security`, Linux's Secret Service via
|
|
48
|
+
`secret-tool`), otherwise a `0600` file under the OS config dir
|
|
49
|
+
(`~/.config/whatcha/credentials.json` on Linux, `~/Library/.../whatcha` is
|
|
50
|
+
not used on macOS since the Keychain is tried first, `%APPDATA%\whatcha` on
|
|
51
|
+
Windows). Every other command reads that session and refreshes it as
|
|
52
|
+
needed (a key is never refreshed); there is no `whatcha logout` -- revoke
|
|
53
|
+
a key in the app, or clear the credential store yourself (Keychain Access,
|
|
54
|
+
`secret-tool clear service whatcha-cli account whatcha`, or delete the
|
|
55
|
+
file) if you need to.
|
|
56
|
+
|
|
57
|
+
Email and password can come from `--email`/`--password`, from
|
|
58
|
+
`WHATCHA_EMAIL`/`WHATCHA_PASSWORD`, or (only when neither is set) an
|
|
59
|
+
interactive prompt with the password masked. The env vars exist because an
|
|
60
|
+
AI agent invoking `whatcha` as a subprocess has no TTY to answer a prompt at.
|
|
61
|
+
|
|
62
|
+
**If sign-in is refused (issue #1428):** GoTrue enforces a Cloudflare
|
|
63
|
+
Turnstile challenge on the password grant, and an automated/headless
|
|
64
|
+
browser cannot solve it -- a real user hit exactly this ("Verification
|
|
65
|
+
failed" / "Please complete the verification") trying to sign in an AI
|
|
66
|
+
partner account. `POST /auth/login` also answers a captcha rejection with
|
|
67
|
+
the same generic 401 as a wrong password, so `whatcha` frequently cannot
|
|
68
|
+
tell you which one happened. Do not keep retrying the password in that
|
|
69
|
+
case: use a personal access key (above). A refresh token still works as
|
|
70
|
+
before:
|
|
71
|
+
|
|
72
|
+
```
|
|
73
|
+
whatcha login --token <refresh-token>
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
or set `WHATCHA_TOKEN` to the same value. This calls `POST /auth/refresh`
|
|
77
|
+
directly, which is **not** captcha-gated. The refresh token has to come
|
|
78
|
+
from somewhere that *can* solve the challenge -- a browser or the mobile
|
|
79
|
+
app -- and unlike a key it cannot be limited to read-only or revoked on its
|
|
80
|
+
own, so prefer a key.
|
|
81
|
+
|
|
82
|
+
### `whatcha whoami`
|
|
83
|
+
|
|
84
|
+
```
|
|
85
|
+
whatcha whoami [--json]
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
Asks the API (`GET /me`) who the saved credential is -- `id`, `username`,
|
|
89
|
+
`displayName`, `email` -- plus `authKind` (`"session"` or `"key"`) and
|
|
90
|
+
whether the CLI is switched into a sub-profile. A revoked key shows up here
|
|
91
|
+
as `KEY_REVOKED`.
|
|
92
|
+
|
|
93
|
+
Advanced: if `WHATCHA_SUPABASE_URL` and `WHATCHA_SUPABASE_ANON_KEY` are both
|
|
94
|
+
set, `whatcha login` talks to GoTrue directly instead of through
|
|
95
|
+
`/auth/login`. This does not bypass the captcha (GoTrue enforces it either
|
|
96
|
+
way) but its error responses do say explicitly when a request was rejected
|
|
97
|
+
for a captcha reason, which `whatcha` then reports plainly instead of
|
|
98
|
+
guessing. Nothing in this repo publishes those two values for a checkout to
|
|
99
|
+
read (they are build-time secrets on the mobile/web clients), so this path
|
|
100
|
+
is opt-in and unverified against a live server -- see the PR description.
|
|
101
|
+
|
|
102
|
+
### `whatcha diaries`
|
|
103
|
+
|
|
104
|
+
```
|
|
105
|
+
whatcha diaries [--json]
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
Lists the diaries you can see (your personal shelf, same set `GET /diaries`
|
|
109
|
+
without `groupId` returns -- so not diaries in a system group like Public
|
|
110
|
+
Square). Each one in `--json` also carries `isPublic` and `publicUrl`
|
|
111
|
+
(#1701; `null` unless public) -- see `whatcha publish` for what makes a
|
|
112
|
+
diary public. Working that out costs one `GET /groups` walk plus one
|
|
113
|
+
`GET /diaries/{id}` per diary in a published group; a shelf with no shared
|
|
114
|
+
diaries costs nothing extra.
|
|
115
|
+
|
|
116
|
+
### `whatcha diary-new` / `whatcha invite`
|
|
117
|
+
|
|
118
|
+
```
|
|
119
|
+
whatcha diary-new <name> [--with <@handle>]... [--timezone <tz>] [--description "..."] [--json]
|
|
120
|
+
whatcha invite <diary> <@handle> [--json]
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
A diary written together (#1700) -- an exchange diary with a friend, or with
|
|
124
|
+
an AI partner profile. `diary-new` does what the app's "Write this diary
|
|
125
|
+
with someone" does: it creates a group named after the diary (you own it;
|
|
126
|
+
the plan's limit on owned groups applies), then the diary in that group,
|
|
127
|
+
readable by every member. `--timezone` is an IANA zone (`Asia/Tokyo`) and
|
|
128
|
+
decides which day an entry lands on; without it the server's default is
|
|
129
|
+
used. `--description` (at most 1,000 characters) goes on both. If the diary
|
|
130
|
+
cannot be created, the empty group is deleted again.
|
|
131
|
+
|
|
132
|
+
Membership is the group's, and the API joins nobody without their own
|
|
133
|
+
accept -- there is no "add this user" call. So `--with` (repeatable) and
|
|
134
|
+
`invite` do one of three things per `@handle`:
|
|
135
|
+
|
|
136
|
+
- **One of this login's sub-profiles** (see `profile-add`): it joins on the
|
|
137
|
+
spot. The CLI mints a one-use invite and accepts it *as that profile*,
|
|
138
|
+
with a session for it used once and never saved -- the CLI stays signed
|
|
139
|
+
in as it was.
|
|
140
|
+
- **The profile you are signed in as**: already a member; nothing is sent.
|
|
141
|
+
- **Anybody else** (and the account itself, seen from a sub-profile -- the
|
|
142
|
+
API issues no account session from there): a one-use invite link, valid
|
|
143
|
+
7 days, for them to open and accept, exactly as the app's invite card
|
|
144
|
+
hands out. The `@handle` is only a label for it.
|
|
145
|
+
|
|
146
|
+
Creating an invite is the group owner's, as in the app. `diary-new --json`
|
|
147
|
+
prints `diary` (the created diary), `groupId` and `members`; each member,
|
|
148
|
+
like `invite --json` (which adds `diaryId` and `groupId`), is `handle`,
|
|
149
|
+
`profileId` (`null` when not one of yours), `joined`, `alreadyMember`,
|
|
150
|
+
`inviteUrl`/`expiresAt` (for a link) and `error` (`{code, message}`, when
|
|
151
|
+
that one handle failed). `diary-new` still creates the diary when a member
|
|
152
|
+
fails -- it exits with status 2 and says which, for `whatcha invite` to
|
|
153
|
+
retry. A diary on your personal shelf cannot be shared; start one with
|
|
154
|
+
`diary-new`.
|
|
155
|
+
|
|
156
|
+
### `whatcha publish`
|
|
157
|
+
|
|
158
|
+
```
|
|
159
|
+
whatcha publish <diary> [--off] [--json]
|
|
160
|
+
```
|
|
161
|
+
|
|
162
|
+
Puts a diary on the web for anybody to read, signed in or not, and prints
|
|
163
|
+
where: `https://whatareyoudo.ing/diaries/<id>` (#1701). The API publishes
|
|
164
|
+
groups, not single diaries, so this is the app's "Publish" switch on the
|
|
165
|
+
diary's group (`PUT /groups/{id}/publication`, owner only): **every diary in
|
|
166
|
+
that group its members can read becomes public with it.** A diary from
|
|
167
|
+
`diary-new` has a group of its own, so there that is just the one diary. A
|
|
168
|
+
diary kept to its creator would stay private in a published group, so
|
|
169
|
+
`publish` opens it to the group first (`PUT /diaries/{id}/visibility`,
|
|
170
|
+
reported as `openedToGroup: true`) -- otherwise the printed link would be a
|
|
171
|
+
404. `--off` takes the group back off the web and changes nothing else. A
|
|
172
|
+
diary on your personal shelf cannot be published. `--json` prints
|
|
173
|
+
`diaryId`, `groupId`, `groupName`, `isPublic`, `url` (`null` with `--off`)
|
|
174
|
+
and `openedToGroup`.
|
|
175
|
+
|
|
176
|
+
### `whatcha write`
|
|
177
|
+
|
|
178
|
+
```
|
|
179
|
+
whatcha write <diary> --text "..." [--title "..."] [--tag <tag>]... [--time HH:MM] [--date YYYY-MM-DD] [--json]
|
|
180
|
+
```
|
|
181
|
+
|
|
182
|
+
`--title` and `--tag` (#1665) set the same `content.title` / `content.tags`
|
|
183
|
+
the app does, under the same rule as the text -- nothing somebody else
|
|
184
|
+
wrote is removed: `--title` only fills an entry that has no title yet (an
|
|
185
|
+
existing one is kept, reported as `titleKept: true` and a note on stderr),
|
|
186
|
+
and `--tag` (repeat it for several) only adds to the entry's tags --
|
|
187
|
+
trimmed, exact duplicates dropped, at most 32 in all, 64 characters each.
|
|
188
|
+
|
|
189
|
+
`<diary>` is a diary id or its exact name (case-insensitive; an ambiguous
|
|
190
|
+
name lists the matches and asks for the id instead). `--date`/`--time`
|
|
191
|
+
default to today/now in **the diary's own timezone**, not the machine's --
|
|
192
|
+
that is what decides which diary-day the API's one-entry-per-day rule
|
|
193
|
+
(§11.4) puts the write on.
|
|
194
|
+
|
|
195
|
+
**Appending is always safe.** If the diary-day already has an entry, this
|
|
196
|
+
never sends a body it has not just read:
|
|
197
|
+
|
|
198
|
+
1. No entry yet for that day -- `POST /entries` creates it with your text.
|
|
199
|
+
2. An entry exists -- the entry is read first (`GET /entries/{id}`, to
|
|
200
|
+
carry its title/mood/tags/cover forward unchanged, since those fields
|
|
201
|
+
are full-replace-on-save the same as the body), then `PATCH` with
|
|
202
|
+
`appendBody: true` (fixed in #1424) appends server-side.
|
|
203
|
+
3. If the server does not know `appendBody` (a 422 naming it an
|
|
204
|
+
unrecognized key), the text already read in step 2 is merged locally
|
|
205
|
+
and sent as a plain replacement of what was just read -- never blind.
|
|
206
|
+
4. Either way, the entry is read back once more afterward to confirm the
|
|
207
|
+
old text is still there under the new text. If that check fails,
|
|
208
|
+
`whatcha` exits with status 2 and a loud warning instead of reporting
|
|
209
|
+
success -- see `src/lib/append-entry.ts` for why this exists (it is the
|
|
210
|
+
only defense against a server old enough to silently ignore
|
|
211
|
+
`appendBody` and just replace, which the API's own default
|
|
212
|
+
configuration would in fact do -- see the PR description).
|
|
213
|
+
|
|
214
|
+
### `whatcha read`
|
|
215
|
+
|
|
216
|
+
```
|
|
217
|
+
whatcha read <diary> [--date YYYY-MM-DD] [--json]
|
|
218
|
+
```
|
|
219
|
+
|
|
220
|
+
Defaults to today (diary timezone). Prints title/tags/body; a locked (Time
|
|
221
|
+
Capsule) entry is reported as locked, never shown early. `GET /entries` has
|
|
222
|
+
no `?date=` filter, so this pages through the diary's entries
|
|
223
|
+
newest-first (`src/lib/entry-find.ts`) until it finds that day or passes it
|
|
224
|
+
-- exact, not fuzzy, but not O(1) for a very old date on a very active diary.
|
|
225
|
+
|
|
226
|
+
### `whatcha profiles` / `whatcha switch` / `whatcha profile-add` / `whatcha profile-rm`
|
|
227
|
+
|
|
228
|
+
```
|
|
229
|
+
whatcha profiles [--json]
|
|
230
|
+
whatcha switch <@handle> [--json]
|
|
231
|
+
whatcha switch --account [--json]
|
|
232
|
+
whatcha profile-add <@handle> --name <display name> [--avatar <file>] [--json]
|
|
233
|
+
whatcha profile-rm <@handle> [--json]
|
|
234
|
+
```
|
|
235
|
+
|
|
236
|
+
Sub-accounts (#1538): one login, more than one profile. A sub-profile is an
|
|
237
|
+
ordinary user with its own `@handle`, so after a switch `write`, `read` and
|
|
238
|
+
`diaries` all act as that profile -- none of them takes a flag, and none of
|
|
239
|
+
them knows the feature exists. The saved session simply is that profile.
|
|
240
|
+
|
|
241
|
+
`profiles` marks the current one with `*` and labels the account; `--json`
|
|
242
|
+
adds `remaining`, how many more the plan allows.
|
|
243
|
+
|
|
244
|
+
`profile-add` (#1699) creates one (`POST /me/profiles`, as the app's "Add a
|
|
245
|
+
profile" does): a `@handle` of 3-30 letters, digits, `_` or `-` starting
|
|
246
|
+
with a letter or digit, and a `--name` of at most 80 characters. A taken
|
|
247
|
+
handle or a full plan is the API's refusal. It does not switch -- run
|
|
248
|
+
`whatcha switch <@handle>` for that. `--avatar <file>` (JPEG, PNG, WebP, GIF
|
|
249
|
+
or AVIF, at most 5 MB, checked before anything is created) is set as the
|
|
250
|
+
new profile itself would set it: `POST /me/avatar` with a session for the
|
|
251
|
+
profile, used once and never saved. If the profile is created but the
|
|
252
|
+
avatar fails, the profile stays, `avatarError` says why and the exit status
|
|
253
|
+
is 2. `--json` prints `profile` (`id`, `username`, `displayName`,
|
|
254
|
+
`avatarUrl`, `parentProfileId`) and `avatarError` (`null`, or
|
|
255
|
+
`{code, message}`).
|
|
256
|
+
|
|
257
|
+
`switch --account` is how you come back. The API refuses to mint an account
|
|
258
|
+
session from a sub-profile's session on purpose -- a sub-profile that could
|
|
259
|
+
ask for one would be a way to take the account over -- so `switch` sets the
|
|
260
|
+
account's refresh token aside in the same credential store and `--account`
|
|
261
|
+
spends it. Switching from one sub-profile to a sibling carries it forward
|
|
262
|
+
unchanged. Logged in with a personal access key, it is the key that is set
|
|
263
|
+
aside (`accountKey`), and `--account` goes back to it.
|
|
264
|
+
|
|
265
|
+
`profile-rm` deletes a sub-profile and everything it wrote; the API refuses
|
|
266
|
+
the account itself and the profile currently in use.
|
|
267
|
+
|
|
268
|
+
Billing is the one thing a sub-profile does not have: the account's plan is
|
|
269
|
+
its plan, and a sub-profile's own limits are the account's.
|
|
270
|
+
|
|
271
|
+
### `whatcha wiki`
|
|
272
|
+
|
|
273
|
+
```
|
|
274
|
+
whatcha wiki list [--search <text>] [--group <group-id>] [--limit N] [--cursor <c>] [--json]
|
|
275
|
+
whatcha wiki read <page> [--group <group-id>] [--json]
|
|
276
|
+
whatcha wiki write <page> --text "..." [--image <file>]... [--cover <file>] [--replace] [--message "..."] [--group <group-id>] [--json]
|
|
277
|
+
whatcha wiki cover <page> <file> | --clear [--group <group-id>] [--json]
|
|
278
|
+
```
|
|
279
|
+
|
|
280
|
+
The Experience Wiki (#1664), on the app's own routes: Public Square's
|
|
281
|
+
`/experience-pages`, or with `--group` that group's
|
|
282
|
+
`/groups/:groupId/experience-pages` (#1348; `whatcha diaries --json` shows
|
|
283
|
+
each diary's `groupId`). `<page>` is the page's tag, e.g. `"Kyoto Tower"`
|
|
284
|
+
(a leading `#` is dropped). Who may read or write which page -- group
|
|
285
|
+
membership, a page's Owner and edit policy (#1344), a lock -- is the API's
|
|
286
|
+
call; a page this account cannot see reads as `found: false`, any other
|
|
287
|
+
refusal is printed as the API sent it.
|
|
288
|
+
|
|
289
|
+
`wiki write` appends below the page's current text and creates the page if
|
|
290
|
+
it does not exist; `--replace` saves the text as the page's new version
|
|
291
|
+
instead. Either way every earlier version stays in the page's history. The
|
|
292
|
+
wiki's `PUT` takes no expected revision, so if somebody else saves between
|
|
293
|
+
`write`'s read and its `PUT`, that is reported (`concurrentEdit: true`, a
|
|
294
|
+
warning on stderr, exit status 2) rather than passed off as a clean save --
|
|
295
|
+
their version is in the history to merge back.
|
|
296
|
+
|
|
297
|
+
Images (#1667). `--image <file>` (repeatable) uploads a local image and
|
|
298
|
+
appends `` for it below the text, in the
|
|
299
|
+
order given, one paragraph each; with images, `--text` may be left out.
|
|
300
|
+
`--cover <file>` uploads an image and makes it the page's cover in the same
|
|
301
|
+
save. `wiki cover <page> <file>` sets the cover of an existing page on its
|
|
302
|
+
own, and `wiki cover <page> --clear` removes it. Uploads go through the
|
|
303
|
+
app's own flow (`POST /uploads` into the page's group -- Public Square's for
|
|
304
|
+
the public wiki -- the PUT to the signed URL, then
|
|
305
|
+
`POST /uploads/:id/complete`), so the server's limits apply: JPEG, PNG,
|
|
306
|
+
WebP, GIF or AVIF, at most 40 MB, within the account's storage quota. Both
|
|
307
|
+
are checked before anything is sent -- the type from the file's first
|
|
308
|
+
bytes, not its name -- and so is the page's 20,000-character limit, so a bad
|
|
309
|
+
file or an over-long page uploads nothing. `wiki read` lists each image's
|
|
310
|
+
signed URL (valid for about an hour) after the text, and the cover's above
|
|
311
|
+
it; `--json` adds `media` (`id`, `url`, `mimeType`, `altText`),
|
|
312
|
+
`coverMediaAssetId` and `coverUrl`. `wiki write --json` reports `images`
|
|
313
|
+
(`file`, `mediaAssetId`) and `coverMediaAssetId`.
|
|
314
|
+
|
|
315
|
+
## The `--json` contract
|
|
316
|
+
|
|
317
|
+
Every command accepts `--json`. On success it prints exactly one JSON
|
|
318
|
+
object to stdout: `{"ok": true, ...}`, with the fields documented per
|
|
319
|
+
command above (`diaries`, `entryId`/`mode`/`verified`/`title`/`tags`/`titleKept`
|
|
320
|
+
for `write`, `body`/`title`/`tags`/... for `read`, `pages` / `body` /
|
|
321
|
+
`mode`/`concurrentEdit` for `wiki`, `profile`/`avatarError` for
|
|
322
|
+
`profile-add`, `diary`/`members` for `diary-new`, `url`/`isPublic` for
|
|
323
|
+
`publish`). On failure it prints
|
|
324
|
+
`{"ok": false, "error": {"code", "message"}}` -- still to stdout, so a
|
|
325
|
+
script doing `whatcha ... --json | jq` gets parseable JSON either way,
|
|
326
|
+
without also having to capture stderr.
|
|
327
|
+
|
|
328
|
+
**Never included, on success or failure:** an access token, a refresh
|
|
329
|
+
token, a personal access key, or a password. `whatcha login --json`'s
|
|
330
|
+
output is `{"ok", "userId", "email", "credentialStore"}` (plus
|
|
331
|
+
`"authKind": "key"` for a key) -- the store's name, never its contents.
|
|
332
|
+
|
|
333
|
+
## Tests
|
|
334
|
+
|
|
335
|
+
```
|
|
336
|
+
npm ci
|
|
337
|
+
npm run typecheck
|
|
338
|
+
npm test
|
|
339
|
+
```
|
|
340
|
+
|
|
341
|
+
Every test runs with no network: `tests/fixtures/fake-client.ts` implements
|
|
342
|
+
the same `WhatchaClient` interface the real HTTP client does, so
|
|
343
|
+
`src/lib/append-entry.ts`, the command parsers, and the token store are all
|
|
344
|
+
exercised against an in-memory fake instead of a live API. The token-store
|
|
345
|
+
tests point `WHATCHA_CONFIG_DIR` at a throwaway directory rather than
|
|
346
|
+
touching a real OS keychain or the developer's own config file.
|
|
@@ -0,0 +1,64 @@
|
|
|
1
|
+
"use strict";
|
|
2
|
+
Object.defineProperty(exports, "__esModule", { value: true });
|
|
3
|
+
exports.GoTrueError = void 0;
|
|
4
|
+
exports.signInWithPassword = signInWithPassword;
|
|
5
|
+
class GoTrueError extends Error {
|
|
6
|
+
status;
|
|
7
|
+
errorCode;
|
|
8
|
+
constructor(status, errorCode, message) {
|
|
9
|
+
super(message);
|
|
10
|
+
this.status = status;
|
|
11
|
+
this.errorCode = errorCode;
|
|
12
|
+
this.name = "GoTrueError";
|
|
13
|
+
}
|
|
14
|
+
/**
|
|
15
|
+
* GoTrue's captcha rejection is a 400 whose body names the captcha
|
|
16
|
+
* explicitly (`error_code: "captcha_failed"` on current GoTrue; older
|
|
17
|
+
* versions instead put it in `msg`, e.g. "captcha protection: request
|
|
18
|
+
* disallowed"), unlike a wrong password's "Invalid login credentials".
|
|
19
|
+
* Not verified against a live server -- see the PR description's "which
|
|
20
|
+
* paths I could verify" section.
|
|
21
|
+
*/
|
|
22
|
+
looksLikeCaptchaFailure() {
|
|
23
|
+
const haystack = `${this.errorCode ?? ""} ${this.message}`.toLowerCase();
|
|
24
|
+
return haystack.includes("captcha");
|
|
25
|
+
}
|
|
26
|
+
}
|
|
27
|
+
exports.GoTrueError = GoTrueError;
|
|
28
|
+
async function signInWithPassword(supabaseUrl, anonKey, email, password, captchaToken) {
|
|
29
|
+
let res;
|
|
30
|
+
try {
|
|
31
|
+
res = await fetch(`${supabaseUrl.replace(/\/$/, "")}/auth/v1/token?grant_type=password`, {
|
|
32
|
+
method: "POST",
|
|
33
|
+
headers: {
|
|
34
|
+
"Content-Type": "application/json",
|
|
35
|
+
apikey: anonKey,
|
|
36
|
+
Authorization: `Bearer ${anonKey}`,
|
|
37
|
+
},
|
|
38
|
+
body: JSON.stringify({
|
|
39
|
+
email,
|
|
40
|
+
password,
|
|
41
|
+
gotrue_meta_security: captchaToken ? { captcha_token: captchaToken } : undefined,
|
|
42
|
+
}),
|
|
43
|
+
});
|
|
44
|
+
}
|
|
45
|
+
catch (err) {
|
|
46
|
+
throw new GoTrueError(0, "network_error", `Could not reach ${supabaseUrl}: ${err.message}`);
|
|
47
|
+
}
|
|
48
|
+
const text = await res.text();
|
|
49
|
+
const json = text ? JSON.parse(text) : undefined;
|
|
50
|
+
if (!res.ok) {
|
|
51
|
+
const body = json;
|
|
52
|
+
const message = body?.msg ?? body?.error_description ?? body?.error ?? `GoTrue answered ${res.status}`;
|
|
53
|
+
throw new GoTrueError(res.status, body?.error_code ?? body?.error, message);
|
|
54
|
+
}
|
|
55
|
+
const body = json;
|
|
56
|
+
return {
|
|
57
|
+
accessToken: body.access_token,
|
|
58
|
+
expiresIn: body.expires_in,
|
|
59
|
+
refreshToken: body.refresh_token,
|
|
60
|
+
userId: body.user.id,
|
|
61
|
+
email: body.user.email ?? email,
|
|
62
|
+
};
|
|
63
|
+
}
|
|
64
|
+
//# sourceMappingURL=gotrue-client.js.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"gotrue-client.js","sourceRoot":"","sources":["../../src/auth/gotrue-client.ts"],"names":[],"mappings":";;;AA2DA,gDA2CC;AAtED,MAAa,WAAY,SAAQ,KAAK;IACf;IAAyB;IAA9C,YAAqB,MAAc,EAAW,SAA6B,EAAE,OAAe;QAC1F,KAAK,CAAC,OAAO,CAAC,CAAC;QADI,WAAM,GAAN,MAAM,CAAQ;QAAW,cAAS,GAAT,SAAS,CAAoB;QAEzE,IAAI,CAAC,IAAI,GAAG,aAAa,CAAC;IAC5B,CAAC;IAED;;;;;;;OAOG;IACH,uBAAuB;QACrB,MAAM,QAAQ,GAAG,GAAG,IAAI,CAAC,SAAS,IAAI,EAAE,IAAI,IAAI,CAAC,OAAO,EAAE,CAAC,WAAW,EAAE,CAAC;QACzE,OAAO,QAAQ,CAAC,QAAQ,CAAC,SAAS,CAAC,CAAC;IACtC,CAAC;CACF;AAlBD,kCAkBC;AASM,KAAK,UAAU,kBAAkB,CACtC,WAAmB,EACnB,OAAe,EACf,KAAa,EACb,QAAgB,EAChB,YAAqB;IAErB,IAAI,GAAa,CAAC;IAClB,IAAI,CAAC;QACH,GAAG,GAAG,MAAM,KAAK,CAAC,GAAG,WAAW,CAAC,OAAO,CAAC,KAAK,EAAE,EAAE,CAAC,oCAAoC,EAAE;YACvF,MAAM,EAAE,MAAM;YACd,OAAO,EAAE;gBACP,cAAc,EAAE,kBAAkB;gBAClC,MAAM,EAAE,OAAO;gBACf,aAAa,EAAE,UAAU,OAAO,EAAE;aACnC;YACD,IAAI,EAAE,IAAI,CAAC,SAAS,CAAC;gBACnB,KAAK;gBACL,QAAQ;gBACR,oBAAoB,EAAE,YAAY,CAAC,CAAC,CAAC,EAAE,aAAa,EAAE,YAAY,EAAE,CAAC,CAAC,CAAC,SAAS;aACjF,CAAC;SACH,CAAC,CAAC;IACL,CAAC;IAAC,OAAO,GAAG,EAAE,CAAC;QACb,MAAM,IAAI,WAAW,CAAC,CAAC,EAAE,eAAe,EAAE,mBAAmB,WAAW,KAAM,GAAa,CAAC,OAAO,EAAE,CAAC,CAAC;IACzG,CAAC;IAED,MAAM,IAAI,GAAG,MAAM,GAAG,CAAC,IAAI,EAAE,CAAC;IAC9B,MAAM,IAAI,GAAY,IAAI,CAAC,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,SAAS,CAAC;IAE1D,IAAI,CAAC,GAAG,CAAC,EAAE,EAAE,CAAC;QACZ,MAAM,IAAI,GAAG,IAAqG,CAAC;QACnH,MAAM,OAAO,GAAG,IAAI,EAAE,GAAG,IAAI,IAAI,EAAE,iBAAiB,IAAI,IAAI,EAAE,KAAK,IAAI,mBAAmB,GAAG,CAAC,MAAM,EAAE,CAAC;QACvG,MAAM,IAAI,WAAW,CAAC,GAAG,CAAC,MAAM,EAAE,IAAI,EAAE,UAAU,IAAI,IAAI,EAAE,KAAK,EAAE,OAAO,CAAC,CAAC;IAC9E,CAAC;IAED,MAAM,IAAI,GAAG,IAA2B,CAAC;IACzC,OAAO;QACL,WAAW,EAAE,IAAI,CAAC,YAAY;QAC9B,SAAS,EAAE,IAAI,CAAC,UAAU;QAC1B,YAAY,EAAE,IAAI,CAAC,aAAa;QAChC,MAAM,EAAE,IAAI,CAAC,IAAI,CAAC,EAAE;QACpB,KAAK,EAAE,IAAI,CAAC,IAAI,CAAC,KAAK,IAAI,KAAK;KAChC,CAAC;AACJ,CAAC"}
|