import type { CompilerExtension } from "@velarscript/compiler";
export interface VelarNodeConfig {
}
export declare const velarProjectExtension: Readonly<{
    id: "@velarscript/node";
    manifestKey: "node";
    parse(value: unknown, manifestPath: string): VelarNodeConfig;
}>;
/**
 * D114 F7-node-b item 2: the path from the directory an emitted entry lands in
 * back to the project root, in the one form the emitted `velar/serve` can join
 * onto `import.meta.dirname` — a `..` chain with `/` separators — or `""` for
 * "there is no offset", which leaves the entry's own directory as the only
 * candidate a relative static root resolves to.
 *
 * Only a pure `..` chain is baked, which is to say: only an output directory
 * *inside* the project. That is a fact about how deep the output sits, not
 * about where the checkout is, so two builds of one project write the same
 * bytes wherever either one runs — the property `output-fingerprint.lock` and
 * `velar verify` both rest on. An `--out-dir` somewhere else on the machine
 * would need the checkout's own absolute path to name the project root, and an
 * output that far from its project is already a relocated artifact: `""` says
 * so, and its assets are the ones sitting beside the entry.
 */
export declare function portableProjectRootOffset(value: unknown): string;
/**
 * The longest `name` a manifest may declare, in UTF-16 code units.
 *
 * A project name is text a person reads, not an npm package name, and a Node
 * build carries it into the emitted `velar/serve` as `name:<name>` — so it is
 * bounded here, once, and 100 code units is more than a name meant to be read
 * ever needs.
 *
 * D114 F10-node, audit NO-I9: two referees judged this bound and disagreed —
 * `assertProjectName` refused past 100 while the identity derivation accepted
 * 214 — so a name only one of them would take could never be reached from a
 * legal manifest. `assertProjectName` imports this constant; `nodeProjectIdentity`
 * writes the same number as a literal, because the emitted copy of that
 * function is evaluated in a Realm that has no module scope to read a constant
 * from. What keeps the two one number is a test rather than a check here:
 * `tests/node/node-static-root.test.ts` reads this constant and drives the
 * derivation at exactly it and one code unit past it. A check that read the
 * function's own source text would be read against a *minified* copy of it in
 * the bundled language server, and would fail for the spelling rather than for
 * the number.
 */
export declare const MAX_PROJECT_NAME_LENGTH = 100;
/**
 * D114 F9-node-cli, audit NO-D1: who the project directory beside an output has
 * to be before that output will serve files out of it.
 *
 * The offset above says *where* the project root would be; it cannot say
 * *whether the directory there is this application's project*. Nothing did, and
 * the answer was taken from `stat().isDirectory()` alone — so a `dist/` copied
 * into `deploy/` beside a stranger's `deploy/public/` published the stranger's
 * files as its own assets, including files the application never had.
 *
 * So the build bakes an identity and the emitted `velar/serve` re-derives it
 * from the `velar.json` it actually finds at `<entry>/<offset>`: the manifest's
 * `name` when it declares one, and otherwise the SHA-256 of the manifest's own
 * text. This function is the one definition of that derivation — `velar/serve`
 * carries its **source** (`NODE_PROJECT_IDENTITY_SOURCE`), the same treatment
 * `routeShapeFromSegments` gets, so the two referees cannot drift. Its body
 * uses only indexed access, `.length` and primitive string concatenation,
 * because the Realm that re-derives it assumes every prototype is hostile.
 *
 * D114 F10-node, audit NO-D1: the second half used to be the project-relative
 * path of the declared entry, on the reasoning that an identity must not change
 * when a field of `velar.json` that has nothing to do with identity is edited.
 * That reasoning was right about edits and wrong about identity: the entry
 * defaults to `src/main.vel` when a manifest declares none, and all six
 * templates write exactly that, so **every** project without a `name` carried
 * the identity `entry:src/main.vel` — and so did any stranger's directory
 * holding a `velar.json`, `{}` included. A digest of the manifest's own text
 * has no such constant: nothing but this project's manifest produces it. What
 * the old reasoning protected is answered by the caller instead — an output
 * whose manifest changed under it resolves beside its entry and *says so*,
 * once, naming both identities.
 */
export declare function nodeProjectIdentity(name: unknown, manifestDigest: unknown): string;
/**
 * The same definition as JavaScript source, for the `velar/serve` template.
 * Deriving it from the compiled function keeps the rule written once: editing
 * `nodeProjectIdentity` edits both referees.
 */
export declare const NODE_PROJECT_IDENTITY_SOURCE: string;
/**
 * The identity in the one form the emitted module can carry: bounded text, or
 * `""` for "this build knew none". `""` is honest for every caller that is not
 * a build, and it leaves the offset judged by whether the directory is there —
 * which is what a project with no manifest at all, a bare `.vel` file run from
 * its own directory, has to be judged by.
 */
export declare function portableProjectIdentity(value: unknown): string;
/**
 * D114 SV-X1: the extension config the emitted `velar/serve` is rendered from,
 * carrying the offset this output directory sits at and the identity of the
 * project it was compiled from.
 *
 * `standardModuleSource` hands each extension only the slice of the project's
 * extension config filed under **that extension's own id**, and `velar/serve`
 * belongs to whichever extension carries it: `@velarscript/node` for a Node
 * project, `@velarscript/server` for a Server one, which composes Node and
 * re-exports Node's module table under its own id. Writing these facts under
 * `@velarscript/node` alone therefore reached a Node project and nothing else,
 * and a Server project — every `velar create --template node` among them —
 * baked neither, so `staticFiles(root="public")` resolved against the emitted
 * entry's own directory and the author's `public/` was never found. So the
 * extensions this build actually compiles with decide where the facts go, and
 * one extension set that does not carry the module at all — Desktop's — gets
 * nothing, because nothing there would read it.
 *
 * Neither fact is a manifest field and `nodeConfig` still refuses every `node`
 * key: a project cannot write these, because they are facts about the directory
 * *a build* chose and the project it read, not settings. `velar/server`'s
 * `artifactConfiguration` reaches its runtime by the same build-only door, and
 * shares the slice this writes into — hence the merge rather than a replace.
 */
export declare function velarNodeServeProjectConfig(extensionConfig: ReadonlyMap<string, unknown>, extensions: readonly CompilerExtension[], offset: string, identity?: string): ReadonlyMap<string, unknown>;
//# sourceMappingURL=project-config.d.ts.map