@nvl/sveltex-language-server 0.2.0

package/dist/core/svelte-proxy.d.ts

@@ -0,0 +1,100 @@
+import type { InitializeParams, InitializeResult } from 'vscode-languageserver-protocol';
+/**
+ * Resolves the absolute path of `svelte-language-server`'s `bin/server.js`.
+ *
+ * The package's `exports` map intentionally exposes `./bin/server.js`, so a
+ * plain module resolution works from this package's location — the standalone
+ * and Zed scenarios, where the server runs out of `node_modules`.
+ *
+ * A host that has bundled `svelte-language-server` to a sibling file (the VS
+ * Code extension does exactly this — see `packages/vscode-sveltex`) cannot rely
+ * on `node_modules` existing and passes the bundled file's absolute path
+ * explicitly via `override`.
+ *
+ * @param override - An explicit absolute path to use instead of resolving from
+ * `node_modules`. When given, it is returned verbatim.
+ * @throws If `override` is omitted and `svelte-language-server` is not
+ * installed.
+ */
+export declare function resolveSvelteServerPath(override?: string): string;
+/**
+ * Handlers the host server registers with a {@link SvelteProxy} so that
+ * messages _originating_ in the child (diagnostics, log messages, ...) can be
+ * routed back out.
+ *
+ * Both handlers are required (the host always wants to know about
+ * `publishDiagnostics`, `window/logMessage`, `client/registerCapability`,
+ * etc.). `LspProxyHandlers` has them optional, since not every child needs
+ * them.
+ */
+export interface SvelteProxyHandlers {
+    /**
+     * Invoked for every notification the child sends (e.g.
+     * `textDocument/publishDiagnostics`, `window/logMessage`).
+     */
+    onNotification: (method: string, params: unknown) => void;
+    /**
+     * Invoked for every server-to-client request the child sends (e.g.
+     * `client/registerCapability`, `workspace/configuration`). The returned
+     * value is sent back as the response.
+     */
+    onRequest: (method: string, params: unknown) => Promise<unknown>;
+}
+/**
+ * A live connection to a child `svelte-language-server` process.
+ *
+ * Lifecycle: {@link setServerPath} optionally points at a bundled
+ * `bin/server.js`; {@link start} spawns the child and performs the LSP
+ * `initialize` handshake; {@link sendRequest} / {@link sendNotification}
+ * forward messages to it; {@link stop} shuts it down gracefully.
+ */
+export declare class SvelteProxy {
+    #private;
+    constructor(handlers: SvelteProxyHandlers);
+    /**
+     * Overrides the location of the child `svelte-language-server`.
+     *
+     * Standalone use (Zed, the CLI) needs no override — the server is
+     * resolved from `node_modules`. A host that has bundled the server to a
+     * sibling file (the VS Code extension) calls this with that file's
+     * absolute path before {@link start}, since `node_modules` will not
+     * exist at runtime.
+     *
+     * @param serverPath - Absolute path of the child's `bin/server.js`, or
+     * `undefined` to keep resolving from `node_modules`.
+     */
+    setServerPath(serverPath: string | undefined): void;
+    /** The `InitializeResult` returned by the child, available after `start`. */
+    get initializeResult(): InitializeResult | undefined;
+    /** Whether the child process is running and initialized. */
+    get isRunning(): boolean;
+    /**
+     * Forks the child `svelte-language-server` and completes the
+     * `initialize` handshake.
+     *
+     * @param initializeParams - The `initialize` params received by the host
+     * server, forwarded to the child mostly unchanged (the child's root /
+     * capabilities should match the host's so its TypeScript service
+     * resolves the project correctly).
+     * @returns The child's `InitializeResult`.
+     */
+    start(initializeParams: InitializeParams): Promise<InitializeResult>;
+    /**
+     * Forwards a request to the child and resolves with its response.
+     *
+     * @throws If the proxy is not running.
+     */
+    sendRequest<R = unknown>(method: string, params: unknown): Promise<R>;
+    /**
+     * Forwards a notification to the child.
+     *
+     * No-op if the proxy is not running (notifications are fire-and-forget
+     * and a not-yet-started child must not crash the host).
+     */
+    sendNotification(method: string, params: unknown): Promise<void>;
+    /**
+     * Gracefully shuts the child down: LSP `shutdown` + `exit`, then
+     * disposes the connection and kills the process if it has not exited.
+     */
+    stop(): Promise<void>;
+}

package/dist/core/svelte-proxy.js

@@ -0,0 +1,144 @@
+// File description: `SvelteProxy` — a thin {@link LspProxy} adaptor for the
+// embedded `svelte-language-server`.
+//
+// The mechanics of "spawn a child language server over stdio, do the
+// `initialize` handshake, forward messages, shut down cleanly" live in
+// `LspProxy` (used by the math language server and TexLab as well).
+// `SvelteProxy` keeps two pieces of `svelte-language-server`-specific
+// behaviour around that generic core:
+//
+//   1. `resolveSvelteServerPath` — locating `bin/server.js` (from a host
+//      override or from `node_modules`), and
+//   2. an API that lets the path be supplied *after* construction but before
+//      `start()` (via {@link setServerPath}). That separation is what lets the
+//      VS Code extension, which bundles the server to a sibling file, pass
+//      the bundled path in `initializationOptions` once it arrives.
+//
+// Per-request forwarding (`sendRequest`, `sendNotification`, `stop`, …) is
+// delegated straight through.
+//
+// `svelte-language-server` is not a clean embeddable library: its npm
+// `exports` expose only `.` and `./bin/server.js`, and it drives
+// TypeScript/CSS/HTML semantics itself. The official Svelte VS Code
+// extension therefore spawns `bin/server.js` as a child process and proxies
+// over JSON-RPC; we do the same.
+import { createRequire } from 'node:module';
+import { LspProxy } from './lsp-proxy.js';
+/**
+ * Resolves the absolute path of `svelte-language-server`'s `bin/server.js`.
+ *
+ * The package's `exports` map intentionally exposes `./bin/server.js`, so a
+ * plain module resolution works from this package's location — the standalone
+ * and Zed scenarios, where the server runs out of `node_modules`.
+ *
+ * A host that has bundled `svelte-language-server` to a sibling file (the VS
+ * Code extension does exactly this — see `packages/vscode-sveltex`) cannot rely
+ * on `node_modules` existing and passes the bundled file's absolute path
+ * explicitly via `override`.
+ *
+ * @param override - An explicit absolute path to use instead of resolving from
+ * `node_modules`. When given, it is returned verbatim.
+ * @throws If `override` is omitted and `svelte-language-server` is not
+ * installed.
+ */
+export function resolveSvelteServerPath(override) {
+    if (override)
+        return override;
+    const require = createRequire(import.meta.url);
+    return require.resolve('svelte-language-server/bin/server.js');
+}
+/**
+ * A live connection to a child `svelte-language-server` process.
+ *
+ * Lifecycle: {@link setServerPath} optionally points at a bundled
+ * `bin/server.js`; {@link start} spawns the child and performs the LSP
+ * `initialize` handshake; {@link sendRequest} / {@link sendNotification}
+ * forward messages to it; {@link stop} shuts it down gracefully.
+ */
+export class SvelteProxy {
+    #handlers;
+    /**
+     * An explicit `svelte-language-server` `bin/server.js` path, or
+     * `undefined` to resolve it from `node_modules`. Set via
+     * {@link setServerPath} before {@link start}. See
+     * {@link resolveSvelteServerPath}.
+     */
+    #serverPathOverride;
+    #inner;
+    constructor(handlers) {
+        this.#handlers = handlers;
+    }
+    /**
+     * Overrides the location of the child `svelte-language-server`.
+     *
+     * Standalone use (Zed, the CLI) needs no override — the server is
+     * resolved from `node_modules`. A host that has bundled the server to a
+     * sibling file (the VS Code extension) calls this with that file's
+     * absolute path before {@link start}, since `node_modules` will not
+     * exist at runtime.
+     *
+     * @param serverPath - Absolute path of the child's `bin/server.js`, or
+     * `undefined` to keep resolving from `node_modules`.
+     */
+    setServerPath(serverPath) {
+        this.#serverPathOverride = serverPath;
+    }
+    /** The `InitializeResult` returned by the child, available after `start`. */
+    get initializeResult() {
+        return this.#inner?.initializeResult;
+    }
+    /** Whether the child process is running and initialized. */
+    get isRunning() {
+        return this.#inner?.isRunning ?? false;
+    }
+    /**
+     * Forks the child `svelte-language-server` and completes the
+     * `initialize` handshake.
+     *
+     * @param initializeParams - The `initialize` params received by the host
+     * server, forwarded to the child mostly unchanged (the child's root /
+     * capabilities should match the host's so its TypeScript service
+     * resolves the project correctly).
+     * @returns The child's `InitializeResult`.
+     */
+    async start(initializeParams) {
+        const serverPath = resolveSvelteServerPath(this.#serverPathOverride);
+        // Pass `--stdio` and forward the handlers verbatim; `LspProxyHandlers`
+        // accepts the (more permissive) optional shape, but
+        // `SvelteProxyHandlers` always provides both, so nothing is lost.
+        this.#inner = new LspProxy({ kind: 'fork', module: serverPath, args: ['--stdio'] }, 'svelte-language-server', this.#handlers);
+        return this.#inner.start(initializeParams);
+    }
+    /**
+     * Forwards a request to the child and resolves with its response.
+     *
+     * @throws If the proxy is not running.
+     */
+    async sendRequest(method, params) {
+        if (!this.#inner) {
+            throw new Error('SvelteProxy is not running.');
+        }
+        return this.#inner.sendRequest(method, params);
+    }
+    /**
+     * Forwards a notification to the child.
+     *
+     * No-op if the proxy is not running (notifications are fire-and-forget
+     * and a not-yet-started child must not crash the host).
+     */
+    async sendNotification(method, params) {
+        if (!this.#inner)
+            return;
+        await this.#inner.sendNotification(method, params);
+    }
+    /**
+     * Gracefully shuts the child down: LSP `shutdown` + `exit`, then
+     * disposes the connection and kills the process if it has not exited.
+     */
+    async stop() {
+        const inner = this.#inner;
+        this.#inner = undefined;
+        if (inner)
+            await inner.stop();
+    }
+}

package/dist/core/texlab.d.ts

@@ -0,0 +1,26 @@
+/**
+ * Searches for the TexLab executable — on `PATH`, then in well-known install
+ * directories.
+ *
+ * @param env - The environment to read `PATH` / `PATHEXT` / `HOME` from.
+ * Defaults to `process.env`; injectable so tests can simulate texlab being
+ * present or absent without touching the real environment.
+ * @param extraDirs - Directories searched after `PATH`. Defaults to
+ * {@link wellKnownTexlabDirs}; tests pass `[]` to confine the search to `env`.
+ * @returns The absolute path of the `texlab` executable, or `undefined` if it
+ * cannot be found.
+ *
+ * @remarks
+ * The lookup is cross-platform: on Windows every `PATHEXT` extension is tried,
+ * on POSIX the bare name. A directory that does not exist, or a candidate that
+ * is not executable, is simply skipped — detection never throws.
+ */
+export declare function findTexlab(env?: NodeJS.ProcessEnv, extraDirs?: readonly string[]): string | undefined;
+/**
+ * Whether TexLab is available on this machine.
+ *
+ * @param env - Optional environment override (see {@link findTexlab}).
+ * @param extraDirs - Optional extra-directories override (see
+ * {@link findTexlab}).
+ */
+export declare function isTexlabAvailable(env?: NodeJS.ProcessEnv, extraDirs?: readonly string[]): boolean;

package/dist/core/texlab.js

@@ -0,0 +1,121 @@
+// File description: Robust, cross-platform detection of the TexLab binary.
+//
+// TexLab (https://github.com/latex-lsp/texlab) is a full LaTeX language server
+// shipped as a standalone native executable. When it is installed, the SvelTeX
+// language server forwards hover/completion/... within LaTeX verbatim regions
+// to a spawned `texlab` child. When it is NOT installed, that forwarding is
+// skipped silently — no error, no crash. This module answers the one question
+// that drives that decision: "where is the `texlab` executable?".
+//
+// `PATH` is searched first (split by the platform delimiter; on Windows every
+// `PATHEXT` extension is tried). It is then backed up by a list of well-known
+// install directories: an editor launched from a macOS Dock / Finder, or via a
+// Linux desktop launcher, inherits only a minimal `PATH` — often just
+// `/usr/bin:/bin:/usr/sbin:/sbin` — that omits `/usr/local/bin`, Homebrew and
+// `~/.cargo/bin`, exactly where `texlab` tends to live. Each candidate is
+// probed with `fs.accessSync(..., X_OK)`; detection never throws.
+import { accessSync, constants } from 'node:fs';
+import { delimiter, join } from 'node:path';
+/** The base name of the TexLab executable (no extension). */
+const TEXLAB_BASENAME = 'texlab';
+/** Whether the host platform is Windows. */
+function isWindows() {
+    return process.platform === 'win32';
+}
+/** The fallback Windows executable extensions when `PATHEXT` is unset. */
+const DEFAULT_PATHEXT = ['.EXE', '.CMD', '.BAT', '.COM'];
+/**
+ * The executable file extensions to try for a bare command name.
+ *
+ * On Windows a command may be `texlab.exe`, `texlab.cmd`, ...; the set comes
+ * from `PATHEXT`. On POSIX there is no extension, so a single empty string is
+ * used.
+ *
+ * @param env - The environment to read `PATHEXT` from.
+ */
+function executableExtensions(env) {
+    if (!isWindows())
+        return [''];
+    const pathext = env['PATHEXT'];
+    if (!pathext)
+        return [...DEFAULT_PATHEXT];
+    return pathext.split(';').filter((ext) => ext.length > 0);
+}
+/** Whether `file` exists and is executable. */
+function isExecutable(file) {
+    try {
+        accessSync(file, constants.X_OK);
+        return true;
+    }
+    catch {
+        return false;
+    }
+}
+/**
+ * Directories `texlab` is commonly installed into but which a GUI-launched
+ * editor's `PATH` frequently omits.
+ *
+ * Searched _after_ `PATH`, as a fallback. Empty on Windows, where the usual
+ * installers (scoop, winget, choco) reliably amend `PATH`.
+ *
+ * @param env - The environment, read for `HOME` to locate `~/.cargo/bin` (the
+ * `cargo install texlab` target) and `~/.local/bin`.
+ */
+function wellKnownTexlabDirs(env) {
+    if (isWindows())
+        return [];
+    const dirs = [
+        '/opt/homebrew/bin', // Homebrew, Apple silicon
+        '/opt/homebrew/sbin',
+        '/usr/local/bin', // Homebrew (Intel) / manual installs
+        '/usr/local/sbin',
+        '/opt/local/bin', // MacPorts
+    ];
+    const home = env['HOME'];
+    if (home) {
+        dirs.push(join(home, '.cargo', 'bin'), join(home, '.local', 'bin'));
+    }
+    return dirs;
+}
+/**
+ * Searches for the TexLab executable — on `PATH`, then in well-known install
+ * directories.
+ *
+ * @param env - The environment to read `PATH` / `PATHEXT` / `HOME` from.
+ * Defaults to `process.env`; injectable so tests can simulate texlab being
+ * present or absent without touching the real environment.
+ * @param extraDirs - Directories searched after `PATH`. Defaults to
+ * {@link wellKnownTexlabDirs}; tests pass `[]` to confine the search to `env`.
+ * @returns The absolute path of the `texlab` executable, or `undefined` if it
+ * cannot be found.
+ *
+ * @remarks
+ * The lookup is cross-platform: on Windows every `PATHEXT` extension is tried,
+ * on POSIX the bare name. A directory that does not exist, or a candidate that
+ * is not executable, is simply skipped — detection never throws.
+ */
+export function findTexlab(env = process.env, extraDirs = wellKnownTexlabDirs(env)) {
+    // `PATH` casing varies (Windows uses `Path`); accept the common forms.
+    const pathValue = env['PATH'] ?? env['Path'] ?? env['path'] ?? '';
+    const extensions = executableExtensions(env);
+    for (const dir of [...pathValue.split(delimiter), ...extraDirs]) {
+        if (dir.length === 0)
+            continue;
+        for (const ext of extensions) {
+            const candidate = join(dir, `${TEXLAB_BASENAME}${ext}`);
+            if (isExecutable(candidate))
+                return candidate;
+        }
+    }
+    return undefined;
+}
+/**
+ * Whether TexLab is available on this machine.
+ *
+ * @param env - Optional environment override (see {@link findTexlab}).
+ * @param extraDirs - Optional extra-directories override (see
+ * {@link findTexlab}).
+ */
+export function isTexlabAvailable(env, extraDirs) {
+    return findTexlab(env, extraDirs) !== undefined;
+}

package/dist/core/virtual-svelte.d.ts

@@ -0,0 +1,32 @@
+import { type Region } from './regions.js';
+import { type Mapping } from './mapping.js';
+import { SourceMap } from './mapper.js';
+/** The result of {@link buildVirtualSvelte}. */
+export interface VirtualSvelteDocument {
+    /** Full text of the generated `.svelte` document. */
+    text: string;
+    /** Span pairs linking the generated document to the source document. */
+    mappings: Mapping[];
+    /** A ready-to-use bidirectional mapper over {@link mappings}. */
+    sourceMap: SourceMap;
+}
+/**
+ * Builds the virtual `.svelte` document for a `.sveltex` source file.
+ *
+ * @param source - Full text of the `.sveltex` document.
+ * @param regions - The document's regions, as returned by `computeRegions`.
+ * Must tile `[0, source.length)` gap-free (which `computeRegions` guarantees).
+ * @returns The generated text, the mappings, and a {@link SourceMap}.
+ *
+ * @remarks
+ * Delegated content reaches the Svelte language server unchanged, so Svelte /
+ * HTML / TypeScript / CSS diagnostics and IntelliSense work exactly as they
+ * would in a real `.svelte` file. Non-delegated content is invisible to that
+ * server (it sees only blanks), which is what stops it from, say, reporting
+ * "unexpected token" inside a block of LaTeX.
+ *
+ * TODO (phase 2): expand Markdown regions to the HTML the Svelte compiler will
+ * actually see, emitting non-identity mappings; the `Mapping` model and
+ * {@link SourceMap} already support differing span lengths.
+ */
+export declare function buildVirtualSvelte(source: string, regions: Region[]): VirtualSvelteDocument;

package/dist/core/virtual-svelte.js

@@ -0,0 +1,67 @@
+// File description: Builds the virtual `.svelte` document that is handed to the
+// embedded Svelte language server, together with the `Mapping[]` that links it
+// back to the source `.sveltex` file.
+//
+// Strategy (v1): delegated regions (plain Markdown/HTML, Svelte markup, mustache
+// tags) are copied byte-for-byte and get an identity `Mapping`; non-delegated
+// regions (verbatim / code / math / frontmatter) are replaced by an equal-length
+// run of whitespace — newlines preserved so line numbers stay aligned — and get
+// NO mapping. Because every region keeps its exact length, the virtual document
+// is the same length as the source, which keeps the geometry trivially correct.
+import { isDelegated } from './regions.js';
+import { identityMapping } from './mapping.js';
+import { SourceMap } from './mapper.js';
+/**
+ * Replaces every non-whitespace character of `slice` with a space, leaving
+ * `\r` and `\n` untouched.
+ *
+ * Keeping the line breaks means a caret on line N of the source sits on line N
+ * of the virtual document too, so even the (unmapped) blanked regions do not
+ * shift anything below them.
+ */
+function blankOut(slice) {
+    return slice.replace(/[^\r\n]/gu, ' ');
+}
+/**
+ * Builds the virtual `.svelte` document for a `.sveltex` source file.
+ *
+ * @param source - Full text of the `.sveltex` document.
+ * @param regions - The document's regions, as returned by `computeRegions`.
+ * Must tile `[0, source.length)` gap-free (which `computeRegions` guarantees).
+ * @returns The generated text, the mappings, and a {@link SourceMap}.
+ *
+ * @remarks
+ * Delegated content reaches the Svelte language server unchanged, so Svelte /
+ * HTML / TypeScript / CSS diagnostics and IntelliSense work exactly as they
+ * would in a real `.svelte` file. Non-delegated content is invisible to that
+ * server (it sees only blanks), which is what stops it from, say, reporting
+ * "unexpected token" inside a block of LaTeX.
+ *
+ * TODO (phase 2): expand Markdown regions to the HTML the Svelte compiler will
+ * actually see, emitting non-identity mappings; the `Mapping` model and
+ * {@link SourceMap} already support differing span lengths.
+ */
+export function buildVirtualSvelte(source, regions) {
+    const chunks = [];
+    const mappings = [];
+    let generatedOffset = 0;
+    for (const region of regions) {
+        const slice = source.slice(region.sourceStart, region.sourceEnd);
+        if (isDelegated(region.kind)) {
+            // Copy verbatim and record an identity mapping.
+            chunks.push(slice);
+            mappings.push(identityMapping(region.sourceStart, generatedOffset, slice.length));
+        }
+        else {
+            // Blank out; emit no mapping so requests here are dropped.
+            chunks.push(blankOut(slice));
+        }
+        generatedOffset += slice.length;
+    }
+    const text = chunks.join('');
+    return {
+        text,
+        mappings,
+        sourceMap: SourceMap.create(mappings, source, text),
+    };
+}

package/dist/index.d.ts

@@ -0,0 +1,29 @@
+export { createServer } from './core/server.js';
+export type { Region, RegionKind } from './core/regions.js';
+export { computeRegions, isDelegated } from './core/regions.js';
+export type { Mapping, MappingFeatures } from './core/mapping.js';
+export { SourceMap } from './core/mapper.js';
+export type { MapDirection } from './core/mapper.js';
+export { buildVirtualSvelte } from './core/virtual-svelte.js';
+export type { VirtualSvelteDocument } from './core/virtual-svelte.js';
+export type { MathBackend, SveltexConfigSnapshot } from './core/config.js';
+export { defaultConfigSnapshot, loadConfigSnapshot } from './core/config.js';
+export { buildRegionVirtualDocument, type RegionVirtualDocument, } from './core/region-virtual.js';
+export { findTexlab, isTexlabAvailable } from './core/texlab.js';
+export { RegionForwarder, isLatexVerbatimRegion, } from './core/region-forwarding.js';
+export { LspProxy, type LspSpawnSpec } from './core/lsp-proxy.js';
+/**
+ * Starts the SvelTeX language server over stdio.
+ *
+ * Creates an LSP connection bound to the current process's standard streams,
+ * wires it up with {@link createServer}, and begins listening. The returned
+ * promise never resolves under normal operation — the process lives as long as
+ * the connection does.
+ *
+ * @remarks
+ * Editors that spawn the server as a child process and talk LSP over stdio
+ * (the Zed extension will do exactly this) need only run `bin/server.js`, which
+ * calls this function. The VS Code extension instead runs the server over an
+ * IPC transport via `vscode-languageclient`, but still through `bin/server.js`.
+ */
+export declare function startServer(): void;

package/dist/index.js

@@ -0,0 +1,46 @@
+// File description: Public entry point of `@nvl/sveltex-language-server`.
+//
+// Two things are exported:
+//
+//  - `createServer(connection)` — the transport-agnostic core. A host that
+//    already owns an LSP `Connection` (e.g. the VS Code extension running the
+//    server in-process, or a test harness) calls this directly.
+//
+//  - `startServer()` — a stdio convenience wrapper: it creates a connection on
+//    `process.stdin`/`process.stdout`, hands it to `createServer`, and starts
+//    listening. This is what `bin/server.js` invokes, and what any editor
+//    (VS Code, Zed, ...) gets when it launches the binary over stdio.
+// The Node-flavoured `createConnection(options?)` lives in the package's node
+// entry point. `vscode-languageserver`'s `typings` field points at the
+// _common_ (browser) API, so importing the concrete node file path is what
+// surfaces the correct overload under `Node16` module resolution.
+import { ProposedFeatures, createConnection, } from 'vscode-languageserver/lib/node/main.js';
+import { createServer } from './core/server.js';
+export { createServer } from './core/server.js';
+export { computeRegions, isDelegated } from './core/regions.js';
+export { SourceMap } from './core/mapper.js';
+export { buildVirtualSvelte } from './core/virtual-svelte.js';
+export { defaultConfigSnapshot, loadConfigSnapshot } from './core/config.js';
+export { buildRegionVirtualDocument, } from './core/region-virtual.js';
+export { findTexlab, isTexlabAvailable } from './core/texlab.js';
+export { RegionForwarder, isLatexVerbatimRegion, } from './core/region-forwarding.js';
+export { LspProxy } from './core/lsp-proxy.js';
+/**
+ * Starts the SvelTeX language server over stdio.
+ *
+ * Creates an LSP connection bound to the current process's standard streams,
+ * wires it up with {@link createServer}, and begins listening. The returned
+ * promise never resolves under normal operation — the process lives as long as
+ * the connection does.
+ *
+ * @remarks
+ * Editors that spawn the server as a child process and talk LSP over stdio
+ * (the Zed extension will do exactly this) need only run `bin/server.js`, which
+ * calls this function. The VS Code extension instead runs the server over an
+ * IPC transport via `vscode-languageclient`, but still through `bin/server.js`.
+ */
+export function startServer() {
+    const connection = createConnection(ProposedFeatures.all);
+    createServer(connection);
+    connection.listen();
+}

package/package.json

@@ -0,0 +1,73 @@
+{
+  "name": "@nvl/sveltex-language-server",
+  "version": "0.2.0",
+  "description": "Language Server Protocol implementation for SvelTeX (Svelte + Markdown + LaTeX)",
+  "type": "module",
+  "license": "MIT",
+  "author": {
+    "name": "N. V. Lang",
+    "email": "npm@nvlang.dev",
+    "url": "https://nvlang.dev/"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/nvlang/sveltex.git",
+    "directory": "packages/sveltex-language-server"
+  },
+  "bugs": {
+    "url": "https://github.com/nvlang/sveltex/issues"
+  },
+  "homepage": "https://sveltex.dev",
+  "keywords": [
+    "sveltex",
+    "svelte",
+    "markdown",
+    "latex",
+    "lsp",
+    "language-server"
+  ],
+  "main": "./dist/index.js",
+  "types": "./dist/index.d.ts",
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "default": "./dist/index.js"
+    },
+    "./bin/server.js": "./bin/server.js",
+    "./package.json": "./package.json"
+  },
+  "bin": {
+    "sveltex-language-server": "bin/server.js"
+  },
+  "files": [
+    "dist",
+    "bin",
+    "package.json",
+    "LICENSE",
+    "README.md"
+  ],
+  "engines": {
+    "node": ">=16"
+  },
+  "dependencies": {
+    "svelte-language-server": "^0.18.0",
+    "vscode-languageserver": "^9.0.1",
+    "vscode-languageserver-protocol": "^3.17.5",
+    "vscode-languageserver-textdocument": "^1.0.12",
+    "vscode-uri": "^3.1.0",
+    "@nvl/sveltex": "0.5.0",
+    "@nvl/sveltex-math-language-server": "0.2.0"
+  },
+  "devDependencies": {
+    "@types/node": "^24.10.15",
+    "tslib": "^2.8.1",
+    "typescript": "^6.0.3",
+    "vitest": "^4.1.6"
+  },
+  "scripts": {
+    "clean": "rimraf coverage dist tmp",
+    "build": "pnpm run clean && tsc -p tsconfig.json",
+    "lint": "eslint . && tsc -p tsconfig.json --noEmit",
+    "test": "vitest run"
+  }
+}