/**
 * Compose the view patterns for the dev and production servers
 * (stacksjs/stacks#2237).
 *
 * Both servers registered `[userViewsPath, defaultViewsPath]` unconditionally,
 * so every Stacks app served the scaffold's demo storefront as live public
 * routes — `/cart`, `/checkout/payment`, `/orders/:id` — and enumerated them
 * into its sitemap. An analytics SaaS has no business answering `/checkout`.
 *
 * The route registry already lets an app decide what to spread; this is the
 * same lever for views.
 *
 * Shared by both callers on purpose. They are in different packages and have
 * drifted before — `requestContext` is installed twice, differently, which is
 * its own report (#2232) — and a views policy that dev and production disagree
 * about is a defect you only find in production.
 *
 * `exists` is injectable so the resolution is testable without a fixture tree;
 * it defaults to the real filesystem.
 */
export declare function resolveViewPatterns(userViewsPath: string, defaultViewsPath: string, setting: DefaultViewsSetting | undefined, exists?: (path: string) => boolean): ViewPatternResolution;
export declare interface ViewPatternResolution {
  patterns: string[]
  missing: string[]
}
/**
 * Whether an app serves the framework's default views, and which of them.
 *
 * `true` (the default) keeps every default view registered, which is the
 * behaviour every existing app already has. `false` registers the app's own
 * views only. An array registers just the named subtrees of the defaults
 * directory — `['errors', 'emails']` for an app that wants the error pages and
 * the mail previews but not the demo storefront.
 */
export type DefaultViewsSetting = boolean | string[];