deeplink-parity 0.5.0 → 0.5.1
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 +69 -6
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -9,8 +9,7 @@
|
|
|
9
9
|
Checks that what your app **declares** about deep links matches what is actually **hosted** — on both iOS and Android, from one command.
|
|
10
10
|
|
|
11
11
|
```bash
|
|
12
|
-
|
|
13
|
-
npx deeplink-parity ./my-app-ios ./my-app-android
|
|
12
|
+
npx deeplink-parity .
|
|
14
13
|
```
|
|
15
14
|
|
|
16
15
|
```
|
|
@@ -30,6 +29,53 @@ WARN promo.example.com
|
|
|
30
29
|
|
|
31
30
|
<br>
|
|
32
31
|
|
|
32
|
+
## Quick start
|
|
33
|
+
|
|
34
|
+
Nothing to configure. Domains are read from your app and the matching files are fetched
|
|
35
|
+
from them.
|
|
36
|
+
|
|
37
|
+
**One repository** — a monorepo, Flutter, or React Native:
|
|
38
|
+
|
|
39
|
+
```bash
|
|
40
|
+
npx deeplink-parity .
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
**Two repositories** — native iOS and Android, which is the case worth checking:
|
|
44
|
+
|
|
45
|
+
```bash
|
|
46
|
+
npx deeplink-parity ./my-app-ios ./my-app-android
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
**On GitHub Actions**, one line:
|
|
50
|
+
|
|
51
|
+
```yaml
|
|
52
|
+
- uses: actions/checkout@v4
|
|
53
|
+
- uses: camosss/deeplink-parity@v1
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
Findings show up as annotations on the run. Add `sha256` to include the Android signing
|
|
57
|
+
key in the check, and `fail-on: never` to report without failing while an existing backlog
|
|
58
|
+
is cleared.
|
|
59
|
+
|
|
60
|
+
<br>
|
|
61
|
+
|
|
62
|
+
## Contents
|
|
63
|
+
|
|
64
|
+
- [Why](#why)
|
|
65
|
+
- [What it checks](#what-it-checks)
|
|
66
|
+
- [Usage](#usage)
|
|
67
|
+
- [GitHub Action](#github-action)
|
|
68
|
+
- [In CI](#in-ci)
|
|
69
|
+
- [Run it on a schedule](#run-it-on-a-schedule)
|
|
70
|
+
- [Validate before deploying](#validate-before-deploying)
|
|
71
|
+
- [Native, Flutter and React Native](#native-flutter-and-react-native)
|
|
72
|
+
- [Hardened against real projects](#hardened-against-real-projects)
|
|
73
|
+
- [What it does not do](#what-it-does-not-do)
|
|
74
|
+
- [Development](#development)
|
|
75
|
+
- [License](#license)
|
|
76
|
+
|
|
77
|
+
<br>
|
|
78
|
+
|
|
33
79
|
## Why
|
|
34
80
|
|
|
35
81
|
Deep links fail **silently**. There is no crash, no error log, no red test. A user taps a link, the browser opens instead of your app, and they shrug and move on. Nobody finds out for months.
|
|
@@ -81,7 +127,10 @@ npx deeplink-parity [path...] [options]
|
|
|
81
127
|
|
|
82
128
|
--sha256 <fingerprint> Android signing fingerprint to look for in assetlinks.json
|
|
83
129
|
--well-known <dir> Read well-known files from <dir>/<domain>/ instead of the network
|
|
84
|
-
--json Machine-readable output
|
|
130
|
+
--json Machine-readable output on stdout
|
|
131
|
+
--output <file> Also write the JSON result to a file
|
|
132
|
+
--format github GitHub Actions annotations (auto-detected on Actions)
|
|
133
|
+
-h, --help Show this message
|
|
85
134
|
```
|
|
86
135
|
|
|
87
136
|
Pass one path per checkout. A monorepo holding both platforms works as a single path,
|
|
@@ -139,7 +188,7 @@ writes nothing but JSON to stdout; progress notes go to stderr. On GitHub Action
|
|
|
139
188
|
findings are also emitted as annotations, which appear on the run summary and against the
|
|
140
189
|
file when one is involved — set `--format github` to force it elsewhere.
|
|
141
190
|
|
|
142
|
-
### Run it on a schedule
|
|
191
|
+
### Run it on a schedule
|
|
143
192
|
|
|
144
193
|
Your deep-link configuration changes a few times a year. The things that break it do not live in your repo at all:
|
|
145
194
|
|
|
@@ -152,12 +201,26 @@ A pull-request check never sees any of this. **A daily scheduled run does.** See
|
|
|
152
201
|
|
|
153
202
|
### Validate before deploying
|
|
154
203
|
|
|
155
|
-
`--well-known <dir>` reads the files from disk instead of the network, so the web team can
|
|
204
|
+
`--well-known <dir>` reads the files from disk instead of the network, so the web team can
|
|
205
|
+
check staged files before they ship — and CI can run with no egress at all.
|
|
206
|
+
|
|
207
|
+
```
|
|
208
|
+
well-known/
|
|
209
|
+
└── links.example.com/
|
|
210
|
+
├── apple-app-site-association
|
|
211
|
+
└── assetlinks.json
|
|
212
|
+
```
|
|
156
213
|
|
|
157
214
|
```bash
|
|
158
|
-
npx deeplink-parity . --well-known ./
|
|
215
|
+
npx deeplink-parity . --well-known ./well-known
|
|
159
216
|
```
|
|
160
217
|
|
|
218
|
+
This answers a different question, though: whether the app matches the files you intend to
|
|
219
|
+
publish, not whether it matches what is live right now. The failures this tool exists to
|
|
220
|
+
catch — a deploy putting a redirect in front of `/.well-known/`, an expired domain, a
|
|
221
|
+
rotated key — only show up against the real host. Files hosted by an attribution vendor
|
|
222
|
+
cannot be checked offline at all.
|
|
223
|
+
|
|
161
224
|
<br>
|
|
162
225
|
|
|
163
226
|
## Native, Flutter and React Native
|
package/package.json
CHANGED