guard-my-design-system 1.2.0 → 1.3.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 +51 -3
- package/index.mjs +15 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -49,6 +49,22 @@ And what it deliberately ignores: everything that was already there. Even if
|
|
|
49
49
|
the codebase carries years of mess, the guard asks one question of a change:
|
|
50
50
|
does it make things worse?
|
|
51
51
|
|
|
52
|
+
## When the guard is wrong
|
|
53
|
+
|
|
54
|
+
Sometimes an off-system value is the right call: a partner's brand colour, a
|
|
55
|
+
gradient that needs its own stops. Say so on the line above, and the guard
|
|
56
|
+
lets that one line pass:
|
|
57
|
+
|
|
58
|
+
```css
|
|
59
|
+
/* guard-ignore-next-line — partner brand colour, agreed with design */
|
|
60
|
+
background: #e4002b;
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
Works in any file the guard reads (`//` in components, `/* */` in styles).
|
|
64
|
+
The exception is visible in code review by nature, silences exactly one line,
|
|
65
|
+
and keeps working on later pull requests that touch the same line. No config
|
|
66
|
+
file, no rule IDs — a sentence a reviewer can read is the whole mechanism.
|
|
67
|
+
|
|
52
68
|
## Why this exists
|
|
53
69
|
|
|
54
70
|
Nobody can win the argument "please go and clean up the codebase". Everyone can
|
|
@@ -113,6 +129,38 @@ npx guard-my-design-system@latest
|
|
|
113
129
|
|
|
114
130
|
Requires Node 18+ and git.
|
|
115
131
|
|
|
132
|
+
## Not on GitHub?
|
|
133
|
+
|
|
134
|
+
The CLI works anywhere git works; only the comment-posting Action is
|
|
135
|
+
GitHub-specific. On GitLab, the merge request pipeline gets the failing check
|
|
136
|
+
with two lines in `.gitlab-ci.yml`:
|
|
137
|
+
|
|
138
|
+
```yaml
|
|
139
|
+
guard:
|
|
140
|
+
image: node:22
|
|
141
|
+
rules:
|
|
142
|
+
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
|
|
143
|
+
script:
|
|
144
|
+
- git fetch origin $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
|
|
145
|
+
- npx guard-my-design-system@latest --strict --base origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME
|
|
146
|
+
```
|
|
147
|
+
|
|
148
|
+
Bitbucket Pipelines, same idea in `bitbucket-pipelines.yml`:
|
|
149
|
+
|
|
150
|
+
```yaml
|
|
151
|
+
pipelines:
|
|
152
|
+
pull-requests:
|
|
153
|
+
'**':
|
|
154
|
+
- step:
|
|
155
|
+
image: node:22
|
|
156
|
+
script:
|
|
157
|
+
- git fetch origin $BITBUCKET_PR_DESTINATION_BRANCH
|
|
158
|
+
- npx guard-my-design-system@latest --strict --base origin/$BITBUCKET_PR_DESTINATION_BRANCH
|
|
159
|
+
```
|
|
160
|
+
|
|
161
|
+
The verdict prints in the pipeline log and `--strict` fails the step; the
|
|
162
|
+
sticky PR comment stays a GitHub luxury for now.
|
|
163
|
+
|
|
116
164
|
## What makes the verdict trustworthy
|
|
117
165
|
|
|
118
166
|
- **Only added lines are checked.** The existing codebase is never judged,
|
|
@@ -149,9 +197,9 @@ in a pull request:
|
|
|
149
197
|
workflow a read-only token). The guard still runs; the verdict lands in the
|
|
150
198
|
workflow log instead, with a line saying why. The same happens if the
|
|
151
199
|
workflow is missing `pull-requests: write`.
|
|
152
|
-
- **Not on GitHub?**
|
|
153
|
-
|
|
154
|
-
|
|
200
|
+
- **Not on GitHub?** Covered — copy-paste GitLab and Bitbucket recipes live in
|
|
201
|
+
[Not on GitHub?](#not-on-github) above. Only the comment-posting Action is
|
|
202
|
+
GitHub-specific.
|
|
155
203
|
|
|
156
204
|
## The family
|
|
157
205
|
|
package/index.mjs
CHANGED
|
@@ -71,7 +71,21 @@ ignorePrefixes = ignorePrefixes.map((p) => p.replace(/^\.?\//, '').replace(/\/?$
|
|
|
71
71
|
const judged = added.filter(({ file }) => !ignorePrefixes.some((p) => (file + '/').startsWith(p)));
|
|
72
72
|
|
|
73
73
|
const system = learnSystem(cwd, { exclude });
|
|
74
|
-
|
|
74
|
+
let findings = judge(judged, system);
|
|
75
|
+
|
|
76
|
+
// The escape hatch: a `guard-ignore-next-line` comment silences every finding
|
|
77
|
+
// on the line below it. Checked against the file as it stands (not just the
|
|
78
|
+
// diff), so an exception granted last month still protects its line today.
|
|
79
|
+
// Visible in code review by nature — that is the whole safety of it.
|
|
80
|
+
const fileCache = new Map();
|
|
81
|
+
const lineAbove = (file, line) => {
|
|
82
|
+
if (!fileCache.has(file)) {
|
|
83
|
+
try { fileCache.set(file, readFileSync(resolve(cwd, file), 'utf8').split('\n')); }
|
|
84
|
+
catch { fileCache.set(file, []); }
|
|
85
|
+
}
|
|
86
|
+
return fileCache.get(file)[line - 2] ?? '';
|
|
87
|
+
};
|
|
88
|
+
findings = findings.filter((f) => !lineAbove(f.file, f.line).includes('guard-ignore-next-line'));
|
|
75
89
|
|
|
76
90
|
if (flag('json')) {
|
|
77
91
|
console.log(JSON.stringify({ base, addedLines: added.length, findings }, null, 2));
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "guard-my-design-system",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.3.1",
|
|
4
4
|
"description": "Your design system dies one pull request at a time. This makes sure it doesn't. A guard that judges only the lines a change adds, against the system the repo already has, and names the on-system value the author probably meant.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|