import { type BridgeFreshness } from '../bridgeSources.js'; /** * What to do about the C# bridge after the code has been refreshed. * * Both inputs are needed, and *when* they are sampled is the whole point. * `hadBridge` is taken before the update: judged on the after-state alone, a * bridge the update destroyed is indistinguishable from one that was never * built, and the difference is whether the server just lost its write path. * `now` is taken after it: an update that moved the bridge sources leaves the * binary in place, so whether it survived says nothing about whether it is * still the bridge this code expects (#1115). * * none — there was no bridge, so this install does not use writes * optional — the bridge survived and was built from these very sources; * rebuilding is only for a D365FO platform upgrade * required — the update removed a bridge that was there, so the write path * is gone until it is rebuilt * stale — the bridge survived but was built from older sources, so the * new code would run against the old bridge * unstamped — the bridge survived but records no sources (built before the * stamp existed); one rebuild writes the stamp */ export type BridgeAction = 'none' | 'optional' | 'required' | 'stale' | 'unstamped'; export declare function bridgeAction(hadBridge: boolean, now: BridgeFreshness): BridgeAction; /** * Where `npm install -g` runs. Anywhere but the package itself. * * runShell defaults to repoRoot, which for an npm install IS the directory * npm is about to replace — and npm replaces it by renaming it aside first. * Windows refuses to rename a directory that any process has as its working * directory, so the shell and npm spawned there held the very lock that made * the rename fail with EBUSY/EPERM. The home directory is outside every * global prefix npm uses. */ export declare function globalInstallCwd(): string; export declare function updateCommand(opts: { yes?: boolean; }): Promise; //# sourceMappingURL=update.d.ts.map