Skip to main content

​
Client

Client is the main runtime surface. It owns:
  • token and intent resolution
  • gateway connections and sharding
  • the shared TongueStore
  • the ChameleonREST instance
  • event subscription
  • middleware
  • all top-level managers

​
Constructor shape

const client = new Client({
  token: process.env.DISCORD_TOKEN!,
  intents: [IntentBits.GUILDS, IntentBits.GUILD_MESSAGES],
  debug: true,
  cache: {
    messages: 1000,
    guilds: 200
  }
})
Important ClientOptions fields:
  • token
  • intents
  • largeThreshold
  • sharding
  • cache
  • debug

​
Runtime methods

The core lifecycle and event methods are:
  • login()
  • destroy()
  • on(event, listener)
  • once(event, listener)
  • off(event, listener)
  • use(middleware)
  • presence(options)
  • requestGuildMembers(...)
  • getShardForGuild(guildId)
Two runtime methods are easy to overlook, but matter in real bots:
  • presence(...) updates status and activities across shards
  • requestGuildMembers(...) asks Discord to send member chunks for large or offline guild member sets

​
Event typing

Chameleon event handlers narrow through the event name and discriminated unions: 
client.on('MESSAGE_CREATE', (event) => {
  console.log(event.message.content)
})

client.on('INTERACTION_CREATE', (event) => {
  console.log(event.interaction.type)
})
This is one of the strongest parts of the framework’s public type surface.

​
Middleware

Middleware runs between dispatch and listeners: 
client.use(async (event, next) => {
  const started = Date.now()
  await next()
  console.log(event.type, Date.now() - started)
})
Use it for logging, profiling, or coarse policy hooks that should apply to many events.

​
Presence and member chunking

Presence updates are a client-level concern: 
client.presence({
  status: 'online',
  activities: [{ name: 'Shipping releases', type: 0 }]
})
For large guilds or member lookup flows, request member chunks explicitly: 
client.requestGuildMembers({
  guildId,
  limit: 0,
  query: ''
})
That is the gateway-side tool you reach for when cache hydration depends on Discord sending more member data.

​
Store

TongueStore is the shared in-memory cache. It keeps flatter entity collections instead of nested object graphs:
  • guilds
  • channels
  • messages
  • users
  • members
  • roles
  • emojis
  • stickers
Tune the store through ClientOptions.cache when memory shape matters.

​
REST and gateway objects

The client also exposes lower-level infrastructure when you need it:
  • client.rest
  • client.gateway
  • client.gateways
Use them when you are extending the framework, building custom tooling, or debugging transport-level issues. Most application code should stay at the manager layer.

​
Resolver helpers

The builders layer also exports helper resolvers such as resolveUser, resolveChannel, resolveGuild, and resolveRole. These return a cached entity when present, or a lightweight stub with id and a fetch() helper when possible. That is useful when you want to pass references around without forcing an immediate REST call.

​
Attached managers

The main manager properties are:
  • commands
  • components
  • users
  • guilds
  • channels
  • messages
  • collectors
  • webhooks
  • invites
  • autoMod
  • scheduledEvents
  • entitlements
  • stageInstances
  • templates
  • application
  • soundboard
Each manager keeps a focused responsibility. The client is the composition root, not a giant action bag.
Last modified on June 13, 2026