Config File

The CLI reads the project's lakeql.config.ts through @lakeql/config. This is the same config the server uses. There is no CLI-specific config file. The data sources, adapters, and source path all come from lakeql.config.ts.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
import { defineConfig } from "@lakeql/config"
import { trinoAdapterDefinition } from "@lakeql/adapter-trino"

export default defineConfig({
  sourcePath: "src",
  adapters: [trinoAdapterDefinition],
  dataSources: {
    warehouse: {
      adapter: "trino",
      connection: {/* ... */},
    },
  },
})

What the CLI Uses #

• dataSources — introspection and generation commands target a source by name (the --source option), or prompt you to pick one.
• sourcePath — the base path under which generated files are written; commands can override it with --source-path .

Name Prefix #

An optional per-source namePrefix disambiguates generated GraphQL names when two data sources expose a table with the same schema.tableName. It is a defineConfig field — see Name Prefix in the config file reference for its definition, per-target casing rules, and a worked example.

The pull and bulk-pull commands read the resolved data-source config and apply its namePrefix; the create-endpoint command is deliberately prefix-unaware (see Prefix scope below). The prefix takes effect only at generation time: changing it and re-pulling writes renamed files, and stale files from the previous prefix are not removed automatically — delete them yourself.

Prefix scope #

namePrefix applies to pull and bulk-pull, and intentionally not to create-endpoint. This is a design decision, not an inconsistency: the two commands generate different kinds of endpoints.

• pull and bulk-pull introspect a live data source and always generate read-only schemas. Their names are derived entirely from schema and tableName , so a per-source prefix is the mechanism that keeps same-named tables from different sources apart.
• create-endpoint builds from a hand-authored (or previously committed) endpoint.json . Those definitions — including any mutations — are written and owned manually, so their names are whatever the author chose. There is no live source config to read a prefix from, and applying one would silently rename names the author set on purpose.

In short, pulled schemas and manually defined endpoints are separate worlds: automatic prefixing belongs to the generated, read-only side and stays out of the manual side.

Loading Order #

The CLI loads any --env file first, then reads lakeql.config.ts, so a config that reads env.* sees the loaded values. The loaded config is cached for the duration of a command.