fimo 0.16.0-staging.6 → 0.16.0-staging.8

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.
@@ -62,6 +62,25 @@ interface PkgWithDeps {
62
62
  dependencies?: Record<string, string>;
63
63
  devDependencies?: Record<string, string>;
64
64
  }
65
+ interface PkgWithScripts {
66
+ scripts?: Record<string, string>;
67
+ }
68
+ /**
69
+ * Point the build script's `fimo validate` at the exact CLI that scaffolded the
70
+ * project.
71
+ *
72
+ * Inside an npm script a bare `fimo` resolves to whatever is installed in the
73
+ * project, which is normally the pinned dependency — but only when the install
74
+ * is current. The hosted build installs the tree itself and then runs this
75
+ * script, and `validate` is an API client: resolving it from install state
76
+ * means a project can be checked by a different version than the one it pins,
77
+ * which is how a project can look clean locally and fail on publish.
78
+ *
79
+ * Only an exact npm version is pinned. A source checkout resolves to
80
+ * `file:<path>`, which is not an npx spec — and there a bare `fimo` already
81
+ * runs the very binary being developed, which is the point of that flow.
82
+ */
83
+ export declare function rewriteFimoValidateCommand(pkg: PkgWithScripts, pin?: string | null): boolean;
65
84
  /**
66
85
  * Rewrite `fimo` (in dependencies + devDependencies) to the current pin. Only
67
86
  * touches entries that look like a value we own: the template's dist-tag, an old
@@ -164,6 +164,39 @@ function findDevJson(startPath) {
164
164
  current = parent;
165
165
  }
166
166
  }
167
+ /**
168
+ * Point the build script's `fimo validate` at the exact CLI that scaffolded the
169
+ * project.
170
+ *
171
+ * Inside an npm script a bare `fimo` resolves to whatever is installed in the
172
+ * project, which is normally the pinned dependency — but only when the install
173
+ * is current. The hosted build installs the tree itself and then runs this
174
+ * script, and `validate` is an API client: resolving it from install state
175
+ * means a project can be checked by a different version than the one it pins,
176
+ * which is how a project can look clean locally and fail on publish.
177
+ *
178
+ * Only an exact npm version is pinned. A source checkout resolves to
179
+ * `file:<path>`, which is not an npx spec — and there a bare `fimo` already
180
+ * runs the very binary being developed, which is the point of that flow.
181
+ */
182
+ export function rewriteFimoValidateCommand(pkg, pin = resolveFimoPin()) {
183
+ if (!pin || !/^\d+\.\d+\.\d+/.test(pin)) {
184
+ return false;
185
+ }
186
+ const build = pkg.scripts?.build;
187
+ if (typeof build !== 'string') {
188
+ return false;
189
+ }
190
+ // Only the validate invocation. Anything else the script runs through `fimo`
191
+ // is local file work, not an API client, and pinning it would add a fetch for
192
+ // no reason.
193
+ const pinned = build.replace(/\bfimo validate\b/, `npx fimo@${pin} validate`);
194
+ if (pinned === build) {
195
+ return false;
196
+ }
197
+ pkg.scripts.build = pinned;
198
+ return true;
199
+ }
167
200
  /**
168
201
  * Rewrite `fimo` (in dependencies + devDependencies) to the current pin. Only
169
202
  * touches entries that look like a value we own: the template's dist-tag, an old
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "fimo",
3
- "version": "0.16.0-staging.6",
3
+ "version": "0.16.0-staging.8",
4
4
  "description": "Fimo CLI - create, deploy, and manage Fimo projects",
5
5
  "bin": {
6
6
  "fimo": "dist/cli/index.js"
@@ -21,7 +21,7 @@
21
21
  "cmdk": "^1.1.1",
22
22
  "date-fns": "^4.1.0",
23
23
  "embla-carousel-react": "^8.6.0",
24
- "fimo": "0.16.0-staging.6",
24
+ "fimo": "0.16.0-staging.8",
25
25
  "input-otp": "^1.4.2",
26
26
  "isbot": "^5",
27
27
  "lucide-react": "^0.577.0",