Configuring Seyfert

TypeScript Configuration

For Seyfert to work correctly, you need to update your tsconfig.json file and add emitDecoratorMetadata and experimentalDecorators to enable the use of decorators:

tsconfig.json
Recommended

{
    "compilerOptions": {

        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
    }
}

{
    "compilerOptions": {
        "module": "CommonJS",
        "target": "ESNext",
        "moduleResolution": "node",
        "strict": true,
        "esModuleInterop": true,
        "experimentalDecorators": true,
        "emitDecoratorMetadata": true,
        "preserveConstEnums": true,
        "noImplicitAny": true,
        "strictNullChecks": true,
        "strictFunctionTypes": true,
        "noImplicitThis": true,
        "noUnusedLocals": true,
        "noUnusedParameters": true,
        "noImplicitReturns": true,
        "skipLibCheck": true,
        "noErrorTruncation": true,
        "outDir": "./dist",
        "rootDir": "./src",
        "baseUrl": ".",
        "stripInternal": true,
    },
    "exclude": ["node_modules"],
    "include": ["src/**/*"]
}

Selecting the Bot Type

Seyfert supports two types of applications that interact with the Discord API: one based on the gateway (websocket) and another based on the HTTP interaction system.

Each type has a distinct purpose, and it is crucial to understand their differences to choose the one that best suits your needs. If you are unsure which bot type to choose, we recommend using the Gateway option.

Gateway
HTTP

The Gateway client handles all events emitted by Discord, such as messageCreate, interactionCreate, guildCreate, ready, among others.
The available events depend on the intents configured in the client.

Configuration

Once you have modified the tsconfig.json to support decorators, there are a few more steps before you can run your application. Seyfert is set up to automatically load your commands, events, components, and language.

For this, you need to create a file called seyfert.config.mjs in the root folder of your project and add the configuration according to the bot type you selected:

Gateway
HTTP

import { 
const config: {
    bot(data: RuntimeConfig): InternalRuntimeConfig;
    http(data: RuntimeConfigHTTP): InternalRuntimeConfigHTTP;
}
config } from "seyfert";

export default 
const config: {
    bot(data: RuntimeConfig): InternalRuntimeConfig;
    http(data: RuntimeConfigHTTP): InternalRuntimeConfigHTTP;
}
config.
function bot(data: RuntimeConfig): InternalRuntimeConfig
Configurations for the bot.
@param ― data - The runtime configuration data for gateway connections.
@returns ― The internal runtime configuration.
bot({
    
token: string
token: 
var process: NodeJS.Process
process.
NodeJS.Process.env: NodeJS.ProcessEnv
The process.env property returns an object containing the user environment.
See environ(7).
An example of this object looks like:
{
  TERM: 'xterm-256color',
  SHELL: '/usr/local/bin/bash',
  USER: 'maciej',
  PATH: '~/.bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin',
  PWD: '/Users/maciej',
  EDITOR: 'vim',
  SHLVL: '1',
  HOME: '/Users/maciej',
  LOGNAME: 'maciej',
  _: '/usr/local/bin/node'
}
It is possible to modify this object, but such modifications will not be
reflected outside the Node.js process, or (unless explicitly requested)
to other Worker threads.
In other words, the following example would not work:
Terminal window
node -e 'process.env.foo = "bar"' &#x26;&#x26; echo $foo
While the following will:
import { env } from 'node:process';

env.foo = 'bar';
console.log(env.foo);
Assigning a property on process.env will implicitly convert the value
to a string. This behavior is deprecated. Future versions of Node.js may
throw an error when the value is not a string, number, or boolean.
import { env } from 'node:process';

env.test = null;
console.log(env.test);
// => 'null'
env.test = undefined;
console.log(env.test);
// => 'undefined'
Use delete to delete a property from process.env.
import { env } from 'node:process';

env.TEST = 1;
delete env.TEST;
console.log(env.TEST);
// => undefined
On Windows operating systems, environment variables are case-insensitive.
import { env } from 'node:process';

env.TEST = 1;
console.log(env.test);
// => 1
Unless explicitly specified when creating a Worker instance,
each Worker thread has its own copy of process.env, based on its
parent thread's process.env, or whatever was specified as the env option
to the Worker constructor. Changes to process.env will not be visible
across Worker threads, and only the main thread can make changes that
are visible to the operating system or to native add-ons. On Windows, a copy of process.env on a Worker instance operates in a case-sensitive manner
unlike the main thread.
@since ― v0.1.27
env.
string | undefined
BOT_TOKEN ?? "",
    
locations: RCLocations
locations: {
        
RCLocations.base: string
base: "dist", // replace with "src" if using bun
        
RCLocations.commands?: string
commands: "commands"
    },
    
intents?: number | IntentStrings | number[]
intents: ["Guilds"],
    // This configuration is optional, in case you want to receive interactions via HTTP
    // This allows you to use both the gateway and the HTTP webhook
    
publicKey?: string
publicKey: "...", // replace with your public key
    
port?: number
port: 4444, // replace with your application's port
});

import { 
const config: {
    bot(data: RuntimeConfig): InternalRuntimeConfig;
    http(data: RuntimeConfigHTTP): InternalRuntimeConfigHTTP;
}
config } from "seyfert";

const  {
    
const BOT_TOKEN: string
BOT_TOKEN, 
const BOT_APP_ID: string
BOT_APP_ID, 
const BOT_PUBLIC_KEY: string
BOT_PUBLIC_KEY
} = 
var process: NodeJS.Process
process.
NodeJS.Process.env: NodeJS.ProcessEnv
The process.env property returns an object containing the user environment.
See environ(7).
An example of this object looks like:
{
  TERM: 'xterm-256color',
  SHELL: '/usr/local/bin/bash',
  USER: 'maciej',
  PATH: '~/.bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin',
  PWD: '/Users/maciej',
  EDITOR: 'vim',
  SHLVL: '1',
  HOME: '/Users/maciej',
  LOGNAME: 'maciej',
  _: '/usr/local/bin/node'
}
It is possible to modify this object, but such modifications will not be
reflected outside the Node.js process, or (unless explicitly requested)
to other Worker threads.
In other words, the following example would not work:
Terminal window
node -e 'process.env.foo = "bar"' &#x26;&#x26; echo $foo
While the following will:
import { env } from 'node:process';

env.foo = 'bar';
console.log(env.foo);
Assigning a property on process.env will implicitly convert the value
to a string. This behavior is deprecated. Future versions of Node.js may
throw an error when the value is not a string, number, or boolean.
import { env } from 'node:process';

env.test = null;
console.log(env.test);
// => 'null'
env.test = undefined;
console.log(env.test);
// => 'undefined'
Use delete to delete a property from process.env.
import { env } from 'node:process';

env.TEST = 1;
delete env.TEST;
console.log(env.TEST);
// => undefined
On Windows operating systems, environment variables are case-insensitive.
import { env } from 'node:process';

env.TEST = 1;
console.log(env.test);
// => 1
Unless explicitly specified when creating a Worker instance,
each Worker thread has its own copy of process.env, based on its
parent thread's process.env, or whatever was specified as the env option
to the Worker constructor. Changes to process.env will not be visible
across Worker threads, and only the main thread can make changes that
are visible to the operating system or to native add-ons. On Windows, a copy of process.env on a Worker instance operates in a case-sensitive manner
unlike the main thread.
@since ― v0.1.27
env;

export default 
const config: {
    bot(data: RuntimeConfig): InternalRuntimeConfig;
    http(data: RuntimeConfigHTTP): InternalRuntimeConfigHTTP;
}
config.
function http(data: RuntimeConfigHTTP): InternalRuntimeConfigHTTP
Configurations for the HTTP server.
@param ― data - The runtime configuration data for http server.
@returns ― The internal runtime configuration for HTTP.
http({
    
token: string
token: 
const BOT_TOKEN: string
BOT_TOKEN,
    
locations: Omit<RCLocations, "events">
locations: {
        
base: string
base: "dist", // replace with "src" if using bun
        
commands?: string
commands: "commands"
    },
    
applicationId: string
applicationId: 
const BOT_APP_ID: string
BOT_APP_ID,
    
port?: number
port: 3000, // default is 8080
    
publicKey: string
publicKey: 
const BOT_PUBLIC_KEY: string
BOT_PUBLIC_KEY,
});

This is not all, you also need to create a main file called index.ts inside the src folder (specified as base in the configuration) and start using it.

Gateway
HTTP

import { 
class Client<Ready extends boolean = boolean>
Client } from "seyfert";

const 
const client: Client<boolean>
client = new 
new Client<boolean>(options?: ClientOptions): Client<boolean>
Client();

// This will start the connection with the Discord gateway and load commands, events, components, and language (i18n)
const client: Client<boolean>
client.
Client<boolean>.start(options?: Omit<DeepPartial<StartOptions>, "httpConnection">, execute?: boolean): Promise<void>
start();

import { 
class HttpClient
HttpClient } from "seyfert";
import { 
class UwsAdapter
UwsAdapter } from "@slipher/uws-adapter";
// import { GenericAdapter } from "@slipher/generic-adapter";

const 
const client: HttpClient
client = new 
new HttpClient(options?: BaseClientOptions): HttpClient
HttpClient();

const 
const adapter: UwsAdapter
adapter = new 
new UwsAdapter(client: UsingClient): UwsAdapter
UwsAdapter(
const client: HttpClient
client); // You can also pass a `Client` or `WorkerClient`.

// This will start listening at `https://yourweb.xyz/interactions` and load commands, components, and language (i18n)
const client: HttpClient
client.
HttpClient.start(options?: DeepPartial<Omit<StartOptions, "connection" | "eventsDir">>): Promise<void>
start();
const adapter: UwsAdapter
adapter.
UwsAdapter.start(path?: `/${string}`, uwsApp?: TemplatedApp): Promise<void>
start();

If you’re using Cloudflare Workers, we recommend following the guide on their official page.

In addition to the above, you need to configure the appropriate types based on the client you are using:

import type { 
type ParseClient<T extends BaseClient> = T
ParseClient, 
class Client<Ready extends boolean = boolean>
Client, 
class HttpClient
HttpClient, 
class WorkerClient<Ready extends boolean = boolean>
WorkerClient } from 'seyfert';

declare module 'seyfert' {

    interface 
interface UsingClient
UsingClient extends 
type ParseClient<T extends BaseClient> = T
ParseClient<
class Client<Ready extends boolean = boolean>
Client<true>> { }


    interface 
interface UsingClient
UsingClient extends 
type ParseClient<T extends BaseClient> = T
ParseClient<
class HttpClient
HttpClient> { }


    interface 
interface UsingClient
UsingClient extends 
type ParseClient<T extends BaseClient> = T
ParseClient<
class WorkerClient<Ready extends boolean = boolean>
WorkerClient<true>> { }
}

For more information on how to declare types and what you can do with them, visit extending declare module.

Once these steps are completed, your project structure should look like this:

Directorysrc
- Directorycommands/
  - …
- index.ts
package.json
seyfert.config.mjs
tsconfig.json
.env

Getting Started

Commands

i18n

Components and Interactions

Recipes

Tips & Miscellaneous

Configuring Seyfert

TypeScript Configuration

Selecting the Bot Type

Configuration