drop2run 0.1.0 → 0.1.2

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/README.md CHANGED
@@ -2,6 +2,15 @@
2
2
 
3
3
  Publish a static site to [Drop2Run](https://dropto.run) from the command line.
4
4
 
5
+ ```bash
6
+ npm i -g drop2run
7
+ drop2run login
8
+ drop2run deploy dist
9
+ ```
10
+
11
+ Node 20 or newer. `login` opens a browser and stores a token, `deploy` prints the URL. Full
12
+ documentation at [dropto.run/docs/cli](https://dropto.run/docs/cli).
13
+
5
14
  ```
6
15
  drop2run login [--device] Sign in and store a token
7
16
  drop2run logout Remove the stored token
@@ -14,6 +23,7 @@ drop2run rm <site> --yes Delete a site and everything on it
14
23
  drop2run token list List your access tokens
15
24
  drop2run whoami Check the token and whose it is
16
25
  drop2run where Show which token source is in use
26
+ drop2run --version Print the version
17
27
  ```
18
28
 
19
29
  `--json` on any command prints machine-readable output instead of text.
@@ -28,102 +38,50 @@ drop2run init dist # creates a site, writes drop2run.json
28
38
  drop2run deploy # publishes dist to it, no arguments
29
39
  ```
30
40
 
31
- The order is not a convenience. A `deploy` that created a site while a project file sat next to it would
32
- leave the real site untouched and the person looking at a URL they did not expect.
33
-
34
- `rm` is the one command that will not act on what it worked out: it prints the site it would delete and
35
- stops, and only runs with `--yes`. There is no undo — the files go and the subdomain is released — and a
36
- terminal has no confirmation dialog, so the flag is the dialog.
41
+ `deploy` never creates a second site while a `drop2run.json` sits next to it — that would leave the real
42
+ site untouched and you looking at a URL you did not expect.
37
43
 
38
- `token create` and `token revoke` do not exist; see below.
44
+ `rm` prints the site it would delete and stops; it only runs with `--yes`. There is no undo — the files
45
+ go and the subdomain is released.
39
46
 
40
47
  ## Signing in
41
48
 
42
49
  `drop2run login` opens a browser, waits on `127.0.0.1`, and stores the token it is handed in
43
- `~/.config/drop2run/config.json` with mode `0600`.
44
-
45
- Two things about it are worth knowing, because they decide when it works:
50
+ `~/.config/drop2run/config.json` with mode `0600`. It uses PKCE, so there is no client secret to leak.
46
51
 
47
- - **It needs a browser and loopback on the same machine.** The token is delivered by a redirect to a
48
- temporary server this process opens on `127.0.0.1`, which is what keeps it out of clipboards and
49
- scrollback. A remote shell whose browser is on another machine cannot complete that redirect — use
50
- `--device` there.
51
- - **It uses PKCE, so there is no client secret.** A verifier is generated per sign-in and never leaves the
52
- process; only its SHA-256 travels through the browser. A code intercepted anywhere along the way cannot
53
- be exchanged without the verifier.
52
+ It needs a browser and loopback **on the same machine**: the token arrives by redirect to a temporary
53
+ server on `127.0.0.1`, which is what keeps it out of clipboards and scrollback. On a remote shell, use
54
+ `--device` instead.
54
55
 
55
56
  ### `--device`, for a machine with no browser
56
57
 
57
58
  `drop2run login --device` prints a short code and waits. Enter it at <https://dropto.run/device> from any
58
- machine you are signed in on — a phone will do — and the terminal picks up its token.
59
+ machine you are already signed in on — a phone will do — and the terminal picks up its token.
59
60
 
60
- The short code is not the credential: it names the pending request, and approving it releases a long code
61
- that never left the waiting process. Somebody reading it over your shoulder learns which sign-in is
62
- waiting, not how to collect its token. It lasts fifteen minutes and works once.
61
+ The short code is not the credential; it names the pending request, so somebody reading it over your
62
+ shoulder learns which sign-in is waiting, not how to collect its token. It lasts fifteen minutes and
63
+ works once.
63
64
 
64
- For CI, neither flow applies — nothing there can open a browser or approve anything. Create a token at
65
- <https://dropto.run/account/tokens> and either set it in the environment:
65
+ ### CI
66
66
 
67
- ```
68
- DROP2RUN_TOKEN=d2r_...
69
- ```
67
+ Neither flow works in CI — nothing there can open a browser or approve anything. Create a token at
68
+ <https://dropto.run/account/tokens> and set it in the environment:
70
69
 
71
- or put it in `~/.config/drop2run/config.json`:
72
-
73
- ```json
74
- { "token": "d2r_..." }
75
70
  ```
76
-
77
- The environment wins. That is the same file and the same precedence `@drop2run/mcp` uses, so signing in
78
- once covers both.
79
-
80
- `drop2run where` says which source is in force without ever printing the token. That is deliberate: the
81
- output of a command line ends up in issue reports, terminal recordings and CI logs, and "why is it using
82
- the wrong account" is answerable without showing the secret.
83
-
84
- ## What `token create` is not
85
-
86
- The brief's §5 lists `token create|list|revoke`. **Create and revoke cannot exist here**, and that is a
87
- decision rather than an omission: a token that can mint tokens is not a leaked credential but a permanent
88
- one — whoever takes it makes a second, and revoking the first changes nothing because the replacement is
89
- one the owner never made and will not recognise. Both endpoints require a browser session. `gh` and
90
- `vercel` draw the line in the same place.
91
-
92
- `token list` does exist, and answers the question a terminal can answer: which machines are holding a
93
- credential, and which of them has not used it since it was made. It prints prefixes, never secrets.
94
- `token revoke` is refused with a message rather than treated as `list` — somebody will type it, and
95
- listing instead would read as having worked.
96
-
97
- ## Releasing
98
-
99
- `0.0.0` was published to hold the bare name `drop2run` (brief §9.1) and is not a release: what was on the
100
- registry at that point had no `login` at all. `0.1.0` is the first version anybody should install.
101
-
102
- ```bash
103
- cd packages/cli && npm publish
71
+ DROP2RUN_TOKEN=d2r_...
104
72
  ```
105
73
 
106
- `prepublishOnly` builds and runs the tests first, and that is load-bearing rather than tidy: `files` is
107
- `["bin", "dist"]`, `dist` is gitignored, and `bin/drop2run.mjs` imports `../dist/index.js`. A publish from
108
- a checkout that had not been built would ship a package that throws on its first line — at a version
109
- number that can never be reused, because npm burns one even after `unpublish`.
110
-
111
- **No `--provenance`, and not by oversight.** It needs a public repository, and this is a private monorepo;
112
- the flag fails locally with `Automatic provenance generation not supported for provider: null` and would
113
- fail in Actions too. Provenance arrives with the `drop2run-cli` split in brief §9.2 — which has its own
114
- precondition, a `gitleaks` sweep of the whole history rather than of HEAD.
74
+ The environment wins over `~/.config/drop2run/config.json`, and that is the same file and precedence
75
+ `@drop2run/mcp` uses, so signing in once covers both.
115
76
 
116
- Two release chores still outstanding, neither blocking: changesets across `core` `node` `cli`, whose
117
- versions have to move in that order, and the fact that this package is the only one of the four with a
118
- licence field.
77
+ `drop2run where` says which source is in force without printing the token, so "why is it using the wrong
78
+ account" is answerable in an issue report or a CI log.
119
79
 
120
- The bundle itself works. `@drop2run/core` and `@drop2run/node` are resolved by build aliases rather than
121
- installed, and `vite build` folds both into `dist/index.js`, so the tarball has no import pointing at
122
- something npm cannot fetch.
80
+ ## `token create` and `token revoke` do not exist
123
81
 
124
- ## Running it from a checkout
82
+ Both need a browser session, and that is deliberate rather than missing. A token that can mint tokens is
83
+ not a leaked credential but a permanent one: whoever takes it makes a second, and revoking the first
84
+ changes nothing. Make and revoke tokens at <https://dropto.run/account/tokens>.
125
85
 
126
- ```bash
127
- cd packages/cli && npm run build
128
- node bin/drop2run.mjs --help
129
- ```
86
+ `token list` does exist and answers what a terminal can answer — which machines hold a credential, and
87
+ which of them has not used it since it was made. It prints prefixes, never secrets.
package/dist/index.js CHANGED
@@ -1191,7 +1191,7 @@ async function run(argv) {
1191
1191
  const positional = argv.filter((argument) => !argument.startsWith("-"));
1192
1192
  const [command, ...rest] = positional;
1193
1193
  if (argv.includes("--version")) {
1194
- const { version } = await import("./package-C83MaeNf.js").then(
1194
+ const { version } = await import("./package-RiuDiPsO.js").then(
1195
1195
  (module) => module.default
1196
1196
  );
1197
1197
  return { text: version, json: { version }, code: 0 };
@@ -1,5 +1,5 @@
1
1
  const name = "drop2run";
2
- const version = "0.1.0";
2
+ const version = "0.1.2";
3
3
  const description = "Publish a static site to Drop2Run from the command line.";
4
4
  const license = "MIT";
5
5
  const type = "module";
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "drop2run",
3
- "version": "0.1.0",
3
+ "version": "0.1.2",
4
4
  "description": "Publish a static site to Drop2Run from the command line.",
5
5
  "license": "MIT",
6
6
  "type": "module",