You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reduce bridge artifact drift across the app-builder workflow
Fulora's app-facing bridge story had split across generator output,
templates, samples, and CLI workflows. This change moves the
common path toward generated service facades, makes bridge
artifact generation explicit and complete, and teaches `dev`
and `package` to validate manifest-based consistency before
developers fall into stale-contract failures.
The CLI now emits and consumes a bridge artifact manifest,
exposes `--preflight-only` for fast checks, and uses more
stable build invocation defaults for nested CLI-driven bridge
builds in tests and real workflows.
Constraint: Must preserve the existing bridge transport/runtime substrate while improving app-builder DX
Constraint: Must keep legacy service exports available during the transition to `services.*`-style facades
Rejected: Auto-fix missing/stale artifacts inside `dev`/`package` | user explicitly requested manifest/hash consistency rather than implicit mutation
Rejected: Keep timestamp-only freshness checks | too noisy and not authoritative enough for build/TFM drift
Confidence: medium
Scope-risk: moderate
Reversibility: clean
Directive: Keep bridge artifact consistency logic centralized; do not re-spread manifest/hash checks across commands without a shared helper
Directive: If manifest schema changes, update both CLI generation and MSBuild target emission in lockstep
Tested: `dotnet test tests/Agibuild.Fulora.UnitTests/Agibuild.Fulora.UnitTests.csproj -v minimal` (2177 passed)
Tested: Template/sample web builds for React, Vue, Showcase Todo, and AI Chat during implementation
Not-tested: End-to-end desktop runtime behavior after `dev`/`package` preflight warnings on a freshly scaffolded app
|`--output`, `-o`| Output directory for generated `.d.ts` files (auto-detected) |
110
+
|`--output`, `-o`| Output directory for generated bridge artifacts (auto-detected; prefers `src/bridge/generated` when present) |
111
+
112
+
The generated `bridge.manifest.json` records the bridge project identity, artifact directory, build configuration, target framework, bridge assembly hash, and artifact hashes so `fulora dev` and `fulora package` can detect missing or stale generated outputs without relying only on timestamps.
Profiles are the productized shipping path in Fulora. They bundle the recommended defaults for a release scenario so you do not need to remember low-level flags every time.
@@ -30,6 +34,8 @@ Current built-in profiles:
30
34
31
35
You can still override profile defaults with explicit flags. For example, `--runtime linux-x64` or `--channel preview` wins over the profile setting.
32
36
37
+
If you want to verify packaging prerequisites without running publish/pack yet, use `--preflight-only`.
38
+
33
39
### 2. Package command options
34
40
35
41
| Option | Description | Default |
@@ -52,6 +58,14 @@ You can still override profile defaults with explicit flags. For example, `--run
52
58
53
59
If `vpk` is not installed, `fulora package` falls back to copying the `dotnet publish` output into the output directory.
54
60
61
+
Fulora now prints **preflight notes** before packaging when the chosen profile implies extra setup. Typical examples:
62
+
63
+
-`desktop-public` without `vpk`: you will get copied publish output, not installer/update packages
64
+
-`mac-notarized` without `vpk`: the fallback output will not be notarized
65
+
-`mac-notarized` on a non-macOS host: you may need to finish signing/notarization on macOS
66
+
67
+
`fulora package` also checks the bridge artifact manifest (`bridge.manifest.json`) when it can locate a sibling Bridge project. That lets it warn about missing or stale generated bridge files before packaging continues.
68
+
55
69
## Raw Signing And Notarization Flags
56
70
57
71
Most teams should stay on the profile-based path. Use the raw flags below when you need to tune signing behavior for a specific environment.
0 commit comments