When should I use "Core Fields"?

Use this page when you are implementing config core fields in the Configuration area of your bot architecture.

What should I read after "Core Fields"?

Continue with related Configuration pages to connect this concept with practical implementation details.

Core Fields

A reference for every top-level field available in spraxium.config.ts. Learn the purpose, default, and intended scope of each field before configuring it.

Root type reference

The object passed to defineConfig must satisfy SpraxiumCoreConfig. Every field is optional; when omitted, the framework applies a sensible default. The table below covers all top-level keys.

Field	Type	Default	Purpose
debug	boolean	false	Increases diagnostic verbosity across all subsystems.
logger	SpraxiumLoggerConfig	Built-in defaults	Controls log output, token masking, command tracing, and Discord transport.
plugins	SpraxiumPlugin[]	Empty list	Typed entries produced by factory helpers such as defineHttp and defineSchedule.
prefix	PrefixConfig	No prefix commands	Defines prefix character, cooldown policy, and mention behavior.
exceptions	ExceptionOptions	Framework default layout	Maps exception classes to reply layouts and controls error logging.
dev	SpraxiumDevConfig	Sensible watch defaults	Configures the local dev watcher entrypoint, debounce, and file patterns.

debug

The debug flag enables extra diagnostic output across every subsystem. When active, the framework emits additional trace lines during module loading, provider resolution, command registration, and interaction dispatch. This output is intended for troubleshooting and should not stay active in high-throughput production deployments.

The flag accepts a plain boolean or any ConfigEnv expression, so you can scope verbosity to a specific environment.

Value	When active
false	Always off. This is the default when the field is omitted.
true	Always on, regardless of environment. Use only in isolated test environments.
env.isDev	Active in local development. Any NODE_ENV value other than production, neutral, staging, or test.
env.isNeutral	Active in staging and CI. NODE_ENV set to neutral, staging, or test. Recommended baseline for most projects.
env.isProd	Active in production only. Use deliberately and temporarily when diagnosing a live issue.

logger

The logger block controls output policy for the built-in logger. It does not affect business logic. The most commonly configured options are maskTokens (replaces token-like strings with a safe placeholder), commandLogging (emits a trace line on every command dispatch), and discord (sends selected log levels to a webhook channel).

config/logger.config.ts

import type { SpraxiumLoggerConfig } from '@spraxium/core';

export const loggerConfig: SpraxiumLoggerConfig = {
  maskTokens: true,
  commandLogging: true,
  discord: {
    type: 'channel',
    webhookUrl: process.env.LOGGER_WEBHOOK!,
    levels: ['error', 'warn'],
    channelId: '1462519588775395429',
  },
};

plugins

The plugins array collects entries returned by plugin factories. Each entry carries a namespace string and a typed config payload; the framework uses the namespace to route config to the correct plugin at runtime. Plugin factories and first-party options are covered on the Plugin Registration page.

dev

The dev block has a dedicated reference page later in this category covering all watcher fields, supported config filenames, and how environments are resolved at startup.

The prefix block is fully documented in the Prefix Commands category. The exceptions block is fully documented in the Exceptions category.